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1.0 INTRODUCTION AND SUMMARY 


The National Aeronautics and Space Administration Langley Research Center 
Terminal Configured Vehicle Program is an intensive research and 
technology effort to provide improved capability for operating CTOL 
transport aircraft in future high-density terminal areas. This program 
is providing a direction and focal point for developing operating systems 
technology which, in combination with new ATC systems being developed by 
the FAA, could lead to more precise, efficient, and productive 
terminal-area operations. 

The NASA Ames Research Center is beginning a program to develop a 
Man-Vehicle Systems Research Facility with advanced cockpit displays and 
technology representative of future aircraft. This facility will be used 
to address human factor issues pertaining to development and evaluation 
of information requirements using advanced display systems, distribution 
of responsibilities between air crews and ground controllers, and 
automation of air crew functions. 

The United States Air Force Wright Aeronautical Laboratory is planning a 
program to develop crew systems technologies for advanced 
military/commercial transport aircraft operating in the Civil Reserve 
Aircraft Fleet of the 2000 AD time period. 

The Lockheed-Georgia Company and the Lockheed-California Company are 
jointly involved in a multi-faceted and inter-related program to apply 
emerging electronics technology to development of their main product 
lines, military and commercial transport aircraft. 
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All of these programs involve the development of Advanced Concepts 
Research Simulators. 

Recognizing that there might be some elements of commonality in 
facilities to support this research, NASA contracted Lockheed-Georgia 
Company to investigate methods of exploiting this commonality. This task 
investigated what issues industry planned to explore, and what others 
should be investigated by the NASA or by other government agencies. From 
this investigation, functional and basic design requirements for research 
and development simulator facilities necessary to conduct these research 
activities were developed, areas of commonality and similarity 
identified, and methods devised for exploiting this commonality. This 
report documents the results of that study. 

During this study the technology research requirements necessary to 
develop an integrated flight station design for transport aircraft 
operating in the Advanced Air Traffic Management System envisioned for 
the 1990's were investigated. Industry, NASA and other government agency 
research needs and the resulting simulation requirements are documented 
in this report. Basic design and functional requirements for research 
and development simulator facilities with the capabilities to conduct 
these research activities are also included. Areas of commonality are 
discussed and specific recommendations of how to exploit this commonality 
to reduce the design and construction costs are presented. 



2.0 LIST OF SYMBOLS AND ACRONYMS 


ACRS 

ADF 

AFCS 

AFWAL 

AIDS 

ALEC 

APU 

ARC 

ARINC 

ATARS 

ATC 

ATCS 

ATIS 

ATS 

AVE 

A/C 

A/D 

BCAS 

BIT 

CA 

CADC 

CAS 

CAWS 


Advanced Concepts Research Simulator 

Automatic Direction Finder 

Automatic Flight Control System 

Air Force Wright Aeronautical Laboratory 

Aircraft Integrated Data System 

Altitude Echo 

Auxiliary Power Unit 

Ames Research Center 

Aeronautical Radio, Inc. 

Automatic Traffic Advisory and Resolution Service 

Air Traffic Control 

Air Traffic Control System 

Air Terminal Information Service 

Automated Traffic Service 

Air Vehicle Equipment 

Aircraft 

Analog-to-Digital 

Beacon Collision Avoidance System 

Built In Test 

Collision Avoidance 

Central Air Data Computer 

Collision Avoidance System 

Caution and Warning System 

Cockpit Display of Traffic Information 
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CDTI 



CDU 


Control Display Unit 


CGI 

Computer Generated Image 

CPU 

Central Processing Unit 

CRAF 

Civil Reserve Air Fleet 

CRT 

Cathode Ray Tube 

CTOL 

Conventional Take Off and Landing 

DABS 

Discrete Address Beacon System 

DADC 

Digital Air Data Computer 

DADS 

Digital Air Data System 

DME 

Distance Measuring Equipment 

DOF 

Degrees of Freedom 

D/A 

Digital-to-Analog 

D/S 

Digital-to-Synchro 

EADI 

Electronic Attitude Director Indicator 

EFIS 

Electronic Flight Instrument System 

EHSI 

Electronic Horizontal Situation Indicator 

EIA 

Electronic Industry Association 

EL 

Electro-Luminescence 

ELM 

Extended Length Message 

ETO 

Estimated Time Overhead 

FAA 

Federal Aviation Administration 

FMC 

Flight Management Computer 

FMS 

Flight Management System 

FORTRAN 

Formula Translation 

GPS 

Global Positioning System 
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GPWS 

Ground Proximity Warning System 

HF 

High Frequency 

HOL 

High Order Language 

HUD 

Head Up Display 

ID 

Identification 

IEEE 

Institute of Electrical and 
Electronics Engineers 

IFR 

Instrument Flight Rules 

ILS 

Instrument Landing System 

INS 

Inertial Navigation System 

IPC 

Intermittent Positive Control 

IRS 

Inertial Reference System 

I/O 

Input/Output 

LaRC 

Langley Research Center 

LCD 

Liquid Crystal Display 

LED 

Light Emitting Diode 

MFD 

Multifunction Display 

MHRS 

Magnetic Heading Reference System 

MLS 

Microwave Landing System 

MOTAS 

Mission Orientated Terminal Area 
Simulation 

MSAW 

Minimum Safe Altitude Warning 

NASA 

National Aeronautics and Space 
Administration 

OMEGA 

Low Frequency Navigation System 
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PA 

REL 

RNAV 

RPM 

RTC 

RVR 

SATCOM 

SELCAL 

SON 

STOL 

S/D 

TACS 

TCV 

TI 

UHF 

USAF 

VASI 

VFR 

VHF 

VMC 

VOR 


Public Address 

Relative 

Area Navigation 

Revolutions Per Minute 

Real Time Clock 

Runway Visual Range 

Satellite Communication 

Selective Calling System 

Statement of Operational Need 

Short Takeoff and Landing 

Synchro-to-Digital 

Transport Advanced Crew Systems 

Terminal Configured Vehicle 

Texas Instruments 

Ultra High Frequency 

United States Air Force 

Visual Approach Slope Indicator 

Visual Flight Rules 

Very High Frequency 

Visual Meteorological Conditions 

VHF Omni Directional Range Navigation 

Four Dimensional Navigation 
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3.0 RESEARCH NEEDS 


The establishment of the design requirements for a research facility, 
which includes a flight station and electronics complement representative 
of 1990's technology, initially entailed surveying various government 
agencies and industrial facilities for their anticipated research and 
development requirements, and to identify issues that must be resolved 

conjunctive to implementation of changes being considered in the ATC 

system. Both NASA LaRC and ARC submitted lists of their research 
requirements and ground rules for their respective facilities. These 
centers were visited to discuss the types of research planned and to 
obtain a better understanding of the problems involved in developing this 
capability at their facilities. The simulator requirements and ground 
rules for each of these centers is included in Appendix A. 

The Boeing Commercial Airplane Company, the Douglas Aircraft Company and 
the Lockheed-Calif ornia Company were visited to survey additional 
industry simulation requirements. These discussions helped to develop 
the types of issues concerning industry, and to present a more 

representative set of industry's research needs. 

The U.S. Air Force Wright Aeronautical Laboratory's Crew Systems 

Development Branch, AFWAL/FIGR, has in its 5-year plan the development of 
crew station technology for military/commercial CRAF aircraft for 2000 
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AD. This program, TACS 2000, will ultimately involve construction of a 
research simulator. A visit with this agency revealed the simularity of 
issues that must be resolved and the functional similarity of the 

military and commercial flight station and systems. No formal set of 
research needs had been prepared, but some general requirements have been 
established through discussions with personnel involved in the 

development of a SON for the facility. 

The following sections discuss in detail the research requirements that 
were identified in this investigation. Grouped into the following seven 
general categories, these discussions identify issues that must be 
resolved in each category. 

a) Aircraft Operating Techniques 

b) New Display Technology and Criteria 

c) Flight Station Integration 

d) Flying Qualities and Control Systems 

e) Crew Performance 

f) Research Tools 
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g) Flight Hardware Evaluation 



3.1 AIRCRAFT OPERATING TECHNIQUES 


The studies concerned with aircraft operating techniques are 
investigations of the use of advanced equipment, both ground based and 
airborne, to obtain a higher degree of safety and more efficient aircraft 
operation. In addition, a primary goal of studying these techniques is 
to increase the utilization of airport facilities to accommodate the ever 
increasing traffic load. 

Profile descent guidance studies will evaluate the operational benefits 
of straight flight path angle versus parabolic flight paths. This will 
require a definition of the display and flight guidance system 
requirements associated with both types of flight paths. 

A study of curved path navigation techniques will define the types of 
complex trajectories that might be beneficial. Again the information 
display and guidance system requirements must be defined for each 
trajectory. This will require development of the guidance algorithms and 
the allowable tolerances. 

One of the major areas of concern when considering simulation of 1990's 
aircraft is the role of the crew members in the future Air Traffic 
Control environment. The distribution of functions for flight crews and 
air traffic controllers must be investigated in 3-D and 4-D area 
navigation situations for aircraft with and without traffic information 


displayed in the cockpit 



A closely related area requiring research is the degree of automation 
that should be implemented in future aircraft. A study of this subject 
must not only determine the overall degree of improved performance of any 
automation and the anticipated level of acceptance in the aviation 
community, but foremost must determine the affect on the human crew 
member's failure detection ability and skill erosion. 

A natural outgrowth of a 4-D RNAV system with metering and spacing is the 
development of an ATC environment that will allow more optimum 
operational procedures based on the performance characteristics of each 
aircraft. The area of integrated flight management needs to be expanded 
to operate in this improved environment. 

The determination of the information criteria and the associated 
technology to transfer preflight planning data into the integrated flight 
management system are issues that require research. Voice 
characteristics, crew anthropometric data, and preferential data could be 
inserted into the aircraft at this time and should be investigated to 
determine the feasibility of using this type of information for flight 
station re-configuration. In addition, the possibility of recording 
inflight data for use in debriefing or training needs to be 
investigated. 

There are several research needs that are uniquely military or industrial 
in the development of advanced military aircraft. The first of these 
concerns aerial refueling for both the tanker and receiver. This 
requirement, as far as unique simulation requirements are concerned, is 
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the development of aerial refueling receiver capability. Visual scene 
generation is significantly impacted by this requirement. 

Assault/STOL takeoff and landing studies must also be carried out for new 
military aircraft. New procedures and techniques must be developed using 
fully integrated flight stations with advanced avionics technology. 

Development of air-drop and air-launch capabilities for multipurpose 
military transport aircraft is required. Techniques, procedures and 
development guidelines must be established for aircraft that will enter 
the military inventory in the 1990 to 2000 time frame. 

3.2 NEW DISPLAY TECHNOLOGY AND CRITERIA 

The rapid advances in electronics display technology will present the 
aviation industry with unprecedented potential and flexibility in 
aircraft display techniques. Instead of being limited to the decision of 
where to display data, the option is now expanded to require the designer 
to develop display formats that are optimized for each phase of aircraft 
operation, and to determine when and how these data should be presented 
in the manner most useful to each crew member. 

One of the first areas of research in display technology concerns the use 
of color displays. The benefits of color versus monochromatic displays 
must be evaluated for various categories of application. The impact of 
implementation must be assessed and design criteria must be formulated. 
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The exposure of the displays to high ambient light levels will require 
research into the various contrast enhancement techniques. Design 
guidelines need to be formulated to improve contrast on various types of 
color displays, and near term research needs to be conducted to evaluate 
the effects of multi-color dot matrix display resolution on readability. 

An area of increasing interest in display technology is the feasibility 
of applying holographic technology to HUD or to map displays. Research 
in this area would identify display problems that might be solved or 
simplified by employing holographies. In addition, steroscopic displays 
might be applied to some of these problem areas. 

A potential problem area that requires investigation is the effect on 
landing performance of reduced field of view through a HUD under 
crosswind conditions. This study will require the development of a 
crosswind probability model. 


3.3 FLIGHT STATION INTEGRATION 

Advances in technology have traditionally generated new devices which are 
introduced into the flight station without adequate analysis of overall 
operational requirements. This often results in changes or additions to 
the flight station which adversely effect the overall operation, while 
improving the operation in specific areas. The primary reason that this 
problem developed is due to the use of discrete "standard" instruments, 
arranged in the best possible display format, and the inherent 
limitations of electro- mechanical devices. Until recent times it has 
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been generally impractical or impossible to combine functions. This 
problem can be corrected in future aircraft with the proper integration 
of electronic display devices with highly researched display formats. 
Although various systems must be treated as separate systems, the 
integrated flight station must be evaluated as a total system. 

The display format for primary and secondary flight information will 
require research to develop and evaluate various concepts. The present 
flight instrument system is satisfactory during cruise and for instrument 
approaches under normal conditions. However, when terminal-area 
navigation, high traffic density, low visibility and/or turbulence are 
encountered, the workload and reaction times reach the point where the 
system is marginal at best. Since electronic displays provide almost 
unlimited format flexibility, they may be optimized to any situation. 
This information will depend on the phase of flight, the degree of 
automation and many other factors that must be investigated as a total 
flight system. The formulation of design criteria and an assessment of 
the impact of the implementation on the total system must be conducted. 

Another area of major concern is the CAWS. Several advances in the 
electronics field in recent years have resulted in an unusual opportunity 
to research and establish design criteria for this type of system that 
did not exist previously. The electronic display units with their 
inherent flexibility of display formats, allow more levels of severity to 
be utilized. Coupled with computer generated voice and phase of flight 
logic, a highly sophisticated caution and warning system can be developed 
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that can get the proper attention level and discriminate some level of 
urgency based on other activities that are taking place at the time. 

The optimum use of electronic display units dictates their use for more 
than one display format or, as multi-function displays. Anything less 
relegates them to simply direct replacement for electro-mechanical 
instruments. Switching functions of multi-function display units need to 
be defined as a part of overall integration into the flight station and 
various design concepts must be evaluated. The impact of implementing 
this technique must be assessed and design criteria must be formulated. 

Maintenance monitoring and systems monitoring display systems will 
require significant research to define the switching modes and format 
content requirements. Various methods of data output must be 
investigated and design criteria established. The impact of these 
systems on the total integration of the flight station and crew duties 
must be assessed. 

The two/three person crew complement issue needs to be researched to 
obtain factual information in all phases of flight. Data on safety, 
aircraft performance, crew coordination, and fatigue must be compiled to 
assess the impact on overall systems design and crew station 
integration. 

Extensive research is required in the area of CDTI. The issue of ground 
based versus airborne sensor information will require study, especially 
in failure modes; however, the design and evaluation of the display 
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formats and the associated data requirements will require extensive 
research. This type of information can have a significant impact on 
total system integration due to the high level of concern of crew members 
for traffic separation. 

The total impact of voice recognition and generation systems on crew 
duties, workload and coordination must be thoroughly studied. Various 
algorithms must be evaluated and design criteria formulated for the voice 
systems themselves. Next, system analysis studies should be conducted to 
assess the accuracy, speed and effectiveness of aural transmission of 
information. 

An essential element of the integrated flight station must include new 
approaches to enhance pilot control of the aircraft. The use of center 
sticks or side-stick controllers, for example, affects the general 
arrangement of the flight station and must be a part of any integrated 
flight station research. The primary pilot controller, primary flight 
information display formats, and the pilot-in-the-loop for flying 
qualities research in the manual mode, must be considered as a part of 
the system. 

Any research of an integrated flight station must investigate conflicts 
in information, regardless of the source. The capability to change 
display formats allows the flexibility to transfer information to other 
display units and will also allow input from other independent 
information sources. Recognition of any conflict and the resulting 
resolution will require extensive investigation. 
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3.4 FLYING QUALITIES AND CONTROL SYSTEMS 

One of the traditional uses of flight simulators has been in the 
evaluation of flying qualities. Simulation techniques are still 
extensively used for this purpose and the totally integrated flight 
station and new control techniques require even greater emphasis in this 
area. 

In the past, flying qualities, or control of flight, research has 
emphasized aircraft stability and control characteristics. Research 
results have largely been formulated in terms of vehicle responses to 
pilot control inputs or parameters related to aerodynamic stability such 
as frequency and damping. In recent years, however, the importance of 
other factors has resulted in an expanded concept of flying qualities as 
"those qualities or characteristics of an aircraft that govern the ease 
and precision with which a pilot is able to perform the tasks required in 
support of an aircraft role." In addition to stability and control 
characteristics, other factors such as the flight task, pilot's stress, 
cockpit interface, and aircraft environment also influence flying 
qualities. Also, the flight control characteristics have been taking on 
added influence as new aircraft configurations place larger requirements 
on the flight control system. 

While theoretical analyses are important, flying qualities research is 
most effectively performed with the pilot-in-the-loop. Since flight 
testing is too costly for most research projects, flight simulation is 
the approach usually taken to obtain the necessary data. Closed-loop 
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flying qualities with advanced primary /secondary controls, cockpit 
display formats, and automatic and active control systems must be 
evaluated. Failure modes or probability of failure on new systems must 
be assessed and design criteria formulated. The type of pilot input 
devices such as side stick. Brolly handles, or some other controller and 
fly-by-wire or fly-by-light systems will be areas of continued interest 
and research. 

Digital flight control system requirements and criteria, optimal control 
theory, and fault tolerant digital control system concepts are areas 
requiring research and development. Active control system research and 
development for such items as relaxed static stability system 
requirements and criteria, load alleviation, and structural mode 
suspression will also be the subject of simulation studies. The emphasis 
of these studies will be to enhance man-machine effectiveness, minimize 
probability of. pilot workload saturation conditions, increased flight 
safety, and improved aircraft operational capability. 

Recent government studies have recognized that there are many new system 
design factors which have broad influences on flying qualities and pilot 
workload, which are not currently included in the existing documents on 
flying qualities. Environmental factors such as windshear, digital 
flight control processing capabilities, and the delineation of 
task-oriented piloted flight have all contributed to the need for an 
expanded view of flying qualities. The advent of advanced cockpit 
layouts with CRT displays also has potential implications to the flying 
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qualities criteria. Economic considerations make it essential that the 
design criteria be structured to assure mission effectiveness, flight 
safety and acceptable pilot workload without penalizing cost 
effectiveness. Simulation studies involving closed loop flying qualities 
criteria will be performed on the advanced flight simulation facility. 

3.5 CREW PERFORMANCE 

In addition to the normal research on various flying characteristics and 
total system integration, a research simulator is a useful tool for human 
factors research, which can be conducted at two major levels. The basic 
level concerns individual elements of the flight station, such as a 
specific display format, and can be carried out initially in a part task 
simulator. The other level of research is concerned with the overall 
crew/vehicle system. This type of experimentation requires a very high 
degree of fidelity in the flight station and a full task simulation. The 
latter is the primary area of concern in developing functional 
requirements for the ACRS. 

One specific area of research in this area is human error and aviation 
safety. Analysis of existing data bases can help develop experimental 
scenarios to study crew behavior as a function of specific accident 
scenarios or generic scenarios. 

Another area of increasing concern, considering the rapid advances in 
technology, is the degree of automation. The major issue in this area is 
the degree to which automation is helpful or even desirable from the 
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perspective of crew behavior, workload and perfornance. The two major 
issues that are apparent, and which require extensive research are skill 
errosion and failure detection. 

Development of crew informaton requirements revolves about the question 
of the relative degree of responsibility between the air crews and ground 
controllers. The related issue of display format requirements must be 
derived from the responsibility distribution. 

The greatest demands on configuration flexibility of flight station 
geometry will be exercised by studies of the human factors of advanced 
crew stations. Crew workload and safety considerations will to a great 
extent influence the design and use of many of the advanced systems in 
the 1990's aircraft. Problem solving and decision making will be an 
index of performance for these systems. Resolution of data conflicts and 
system failures is a major area of concern. 

Air crew behavior studies of a generic nature will require the widest 
range of performance measuring equipment. These studies must concern 
themselves with training, crew workload, crew resource management, 
fatigue, and other areas of general significance including crew/vehicle 
performance. 

3.6 RESEARCH TOOLS 

The versatility of display devices will require some preliminary 
guidelines before the possible formats can be narrowed to a population 
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practical to be investigated. This will require analytical studies 

possibily using an analysis tool such as the Optimal Control Model of the 
Human Operator. This type of analysis needs to be applied at the 

information level, display element level and the display format level. 
The comparative human performance at various levels of automation or with 
various display formats requires both workload and performance 
measurement capabilities. Performance measurement techniques in general 
have been refined, but additional research is required to develop 
improved workload measurement and prediction techniques. 

Some areas of interest in workload measurement include the investigation 
of the correlation between various physiological parameters and 
workload. Methods of monitoring and interpreting these physiological 
parameters need to be developed. Full f ield-of-view oculometer systems 
will be required, and the correlation between these data and crew 
workload must be determined. Sensitivity analysis of various parameters 
concerning workload will be very useful in establishing design criteria 
or evaluating specific elements. This will establish the requirement for 
an integrated workload measurement system data reduction and analysis 
package. 

A workload prediction technique that includes improved cognitive and 
visual factor representation should be developed. This will require the 
definition and validation of weighting functions for each workload 
factor. 


20 - 



3.7 FLIGHT HARDWARE EVALUATION 


Flight hardware for future aircraft is usually mathematically modeled 
during the early stages of development or during research. As the 
designs begin to solidify, and as prototype hardware is developed or 
possible supplier hardware evaluations are required, actual hardware 
should be inserted into the simulation process. 

The electronics or avionics interface to the simulation is easier to 
generalize without building a facility for each aircraft. The bus 
systems that are being- used on the newer designs make this a very 
desirable approach. This capability can be used to validate and verify 
operational flight software. Redundancy management, backup modes and 
failure analysis, and sensor control development and evaluation should be 
performed in an electronics integration facility. 

The mechanical, hydraulic and pneumatic simulation capability in general 
must replicate a specific aircraft. This capability is normally required 
during aircraft development, but should be considered during simulator 
design if the capability is desired. 

3.8 RESEARCH NEEDS/ SIMULATOR REQUIREMENTS 

Figure 3-1 is a matrix that tabulates the research needs of industry and 
the various government agencies versus simulator requirements. 
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The shape of the symbol in each quadrant of the requirement blank 
indicates whether the requirement is near term only, far term, or 
required near term and used for an extended period of time. 

Inasmuch as the U. S. Air Force has not developed a complete set of 
research requirements at this time, those shown give some ideas of 
possible areas of similarity that were identified in discussions with 
knowledgeable individuals. Although several agencies may be shown as 
having the same requirements, the degree of the requirement is so 
different that it could be hypotheized that the requirements are indeed 
different. An example of this is the requirement for an ATC function. 
The NASA requirement is for extensive simulation, while the industry 
requirement is little more than communications and navigational aids. 
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FIGURE 3-1 CONCLUDED 



4.0 SIMULATOR REQUIREMENTS 


This section addresses functional requirements and design criteria for 
those elements of the ACRS which are common to both government and 
industrial facilities devoted to advanced flight research. As such, they 
can be easily converted into a detailed design specification for an ACRS 
configured to satisfy the research goals of any particular agency or 
group. 

The design requirements have been- grouped into eight categories which 
address the common elements of the ACRS. These categories are as 
follows: 

a) Hardware components 

b) Flight Station 

c) ATC interface 

d) Computer complex 

e) Environmental systems 

f) Test conductor console 

g) Computer control console 

h) Data acquisition and recording system. 

Specific design requirements applicable to each category are discussed in 
the following sections. 
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4.1 HARDWARE COMPONENTS 


The basic elements of the ACRS are shown in block diagram form in Figure 
4-1 • One of the primary design goals of this study was to explore 
functional commonality among similar facilities located within industry 
and the various government agencies. Certain differences will inevitably 
exist, however, due to the unique research and development roles assigned 
to each simulator. In some implementations of the ACRS concept, for 
example, the host computer will drive a single cockpit as shown in Figure 
4-1; in others, it will simultaneously drive multiple cockpits; in 
others, the host computer will be switched between multiple cockpits. 
Each version of the ACRS will, however, consist of the same basic 
functional elements configured to satisfy specific needs. A typical 
configuration in which multiple cockpits can be selectively driven by a 
single host computer is shown in Figure 4-2. 

The computer complex is recognized to be the heart of any simulation 
facility, and includes the host computer, the I/O system and all 
peripherals necessary to support simulator operation and related software 
development activities. Flight station elements are connected to, and 
driven by the host computer through the I/O system. This provides the 
necessary physical interfaces among the test crew, the simulated 
aircraft, the aircraft systems and all external stimuli. The various 
consoles must allow test and maintenance personnel to exercise control 
over the ACRS and to monitor various aspects of its operation through 
links with the host computer. 
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FIGURE 4-1 . ADVANCED CONCEPTS RESEARCH SIMULATOR 


































While the computer complex must be fully capable of simulating an 
aircraft, its systems, and any desired external effects with a high 
degree of fidelity, provisions must be made for replacing the software 
simulation of any given system with corresponding AVE. Additional 
realism must be provided via the external scene presented by the visual 
system. Multiplex data bus techniques should be used to the extent 
practicable to interconnect the various elements into a functioning 
simulator. If physical motion cues are considered pertinent to the 
research tasks to be accomplished within a particular ACRS, the cockpit 
should be mounted on an appropriate motion base or g-seats should be 
utilized. 

A number of significant physical factors must be considered during design 
of the ACRS. Some of these factors directly affect the degree to which 
the facility would ultimately satisfy its design goals. Others address 
the manner in which the facility could be operated, and the ease with 
which it could be reconfigured or expanded to satisfy changing research 
requirements. Others concern the level of safety provided to the 
physical facility itself, to its operating personnel and to the test 
subjects. 

While not exhaustive, the following discussion is intended to summarize 
some of the more significant considerations affecting the design and 
physical implementation of the ACRS: 

a) One of the first considerations must obviously be the amount of 
physical space available, and its configuration. Each of the basic 



functional elements identified in Figure 4-1 impose certain unique 
physical space requirements. Overall, however, the elements should be 
physically located as close together as possible both to minimize the 
length of physical cable runs, and to facilitate coordination during 
simulator operation and maintenance. Due to the dynamic nature of the 
research environment, space must be provided to accommodate future 
expansion. Particular attention must be given to the space requirements 
of candidate visual and motion systems. 

b) Sufficient electrical power, for future expansion as well as for 
current operation, must be available. As a minimum, the computer complex 
should be provided with a non-interruptible power source. 

c) Adequate cooling air must be provided. Use of modern digital systems 
employing solid state technology tends to lessen this problem somewhat. 
The potential heat problem inherent in the operation of a large amount of 
electronic equipment in a somewhat confined area must be recognized, 
however, and the facility design must include measures to provide 
sufficient cooling to ensure proper operation and to maximize equipment 
life. An alarm system must be provided to sense the occurrence of any 
potential over-temperature situation and to annunciate this fact to 
facility personnel so that immediate corrective action can be taken. 

d) Potential problems related to electromagnetic interference must be 
anticipated and eliminated insofar as possible within the facility 
design. Provision of an adequate electrical grounding scheme for the 
ACRS is mandatory, and it should be designed to absolutely minimize the 
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level of ground noise. Particular care must be taken to ensure that no 
noise signals of any type can enter the computer complex through the 
grounding system. In extreme cases, the computer complex may have to be 
electrically isolated from the remainder of the simulation facility. 

e) To the extent possible, electrical interconnection of the basic 
functional elements should be accomplished via multiplex data buses. In 
addition to providing improved flexibility, use of data bus techniques 
will significantly reduce the amount of physical wiring required within 
the facility. This will dramatically reduce the costs associated with 
initial fabrication of the ACRS and will aid in keeping recurring 
maintenance costs at an acceptable level. 

f) Accessibility of all hardware components and wiring must be stressed 
throughout the design. This will greatly facilitate later implementation 
of facility improvements in addition to providing easy access by facility 
personnel to components during both normal simulator operation and 
maintenance actions. 

g) Adequate lighting must be provided in all areas of the ACRS. 
Particular attention must be given to the need for lighting in all 
confined areas such as equipment racks and underfloor wiring troughs. 

h) A comprehensive intercom system linking all areas of the ACRS must be 
provided. This system should serve at least two basic functions. During 
normal simulator operation, it should provide for the audible 
coordination required among research personnel, and during maintenance 
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periods it should allow facility personnel to communicate among the 
various simulator stations as an aid in the necessary troubleshooting and 
repair operations. 

i) RS232-type data connectors should be installed at strategic locations 
throughout the ACRS. These connectors should be interfaced to the 
computer complex through standard RS232 buses to allow interactive access 
to the various computers, and to the I/O system via CRT-type or portable 
data terminals. As such, these terminals can be used to control the 
operation of certain portions of the ACRS in order to implement temporary 
software changes or to perform various maintenance actions. The 
availability of these data connectors at sites throughout the facility 
will prove to be quite useful in normal day- to-day simulator 
operations. 

j) All other factors aside, the overriding consideration in the design of 
the ACRS must be the physical safety of those who work within it. All 
design decisions must be made with due consideration to their ultimate 
impact upon the safety aspects of the facility. Specific areas of 
concern include provision of fire alarm/protection systems in all areas, 
with particular emphasis upon the cockpit; availablity of emergency 
shutdown switches throughout the facility; provisions to ensure that all 
electrical and/or hydraulic systems have been deactivated as appropriate 
during maintenance operations; and provision of protective systems to 
prevent injury to personnel in the event of failure of 
hydraulically-driven hardware such as the control loading system or the 


- 32 - 



motion system. The specific areas just mentioned are intended merely to 
indicate the types of safety considerations which must be included within 
the design. They do not constitute an all-inclusive list. Every area 
must be carefully examined during the design phase to determine any 
factors which might ultimately compromise the safety of the operators and 
users of the ACRS. 

4.2 FLIGHT STATION 

4.2.1 DEVELOPMENT PROCESS 

Development of a 1990' s flight station configuration for an advanced 
concepts research facility requires the orderly systems engineering 
approach set forth in the following paragraphs. 

The initial phase of this activity must consist of obtaining, 
forecasting, and determining information on 1990' s user needs, operating 
environment and procedures, and aircraft systems and electronics 
technology. Operational scenarios must be developed using this 
information, and then validated by the users. Detailed time lines can be 
developed from these and used to generate aircraft functional 
requirements, and to determine aircrew information and control 
requirements. 

Following a conceptual description of the aircraft functions required to 
satisfy the mission and environment, those functions and the tasks to 
perform them must then be allocated to either the crew or the machine and 
the input/output relationship between them established. To establish a 



baseline, an initial selection of crew size and complement must be made, 
which will be refined throughout the analysis until a final determination 
can be made. Through the process of time lines, task loading, trade-off 
analyses, and reallocation of functions between crew members, and between 
the crew and the machine, an equalized and logical task loading for the 
crew members can be derived. A feedback of design solutions through the 
system will determine by a functional analysis if the information/action 
requirements are met. 

Aircraft subsystems such as fuel, electrical, and hydraulics must be 
designed and configured to reflect 1990's technology, and requirements 
for display and control devices for these as well as the communications, 
guidance, and navigation functions determined. These designs must 
consider and be responsive to the facility functional requirements and 
research needs identified previously. Technology forecasts developed 
earlier in the program for displays and system operating controls must 
guide the selection of the technologies which will be available in the 
1990's time period. When this is accomplished, functional layouts of the 
various crew stations can then be made. These should consider primarily 
the categorization of each information/action item as to its importance 
from the standpoint of reach, vision, or other sensory perception. 
Conceptual/actual candidate crew systems will be the result of this 
effort. 

Upon incorporation of these designs in a mockup, critical segments of the 
scenarios developed earlier can be "flown" by proficient test subjects to 
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evaluate and validate the various design options. The testing must be 
iterative, and must examine all candidate designs. Subjective 
performance data must be collected during and following mockup flying 
sessions through questionnaires and debriefings. These and additional 
objective and subjective workload data must be collected, reduced, and 
the results evaluated. 

From these iterations, simulator design and fabrication can begin. This 
process starts with refining the features of the mockup design found 
necessary during the mockup tests. As with the mockup, components must 
be sized and constructed, crew systems must be designed/selected, and 
control/display layouts made. Hardware must be fabricated, installed, 
integrated with software to operate as systems, and then be thoroughly 
checked against the mission scenario requirements. 

Completion of this process is mandatory to provide an authentic baseline 
configuration that is representative of both projected developments in 
aircraft subsystems technology, as well as displays, controls, and 
systems compatible with the airways and ATC system improvements projected 
for the future. Flexibility and versatility in developing and evaluating 
various display and control hardware, display formats, equipment 
arrangement and location, crew complements, etc. is the key to providing 
a useful research tool. All of these factors, plus providing ease of 
rapid reconfiguration to accommodate efficient conduct of experiments 
must heavily influence the design process. 
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4.2.2 DESIGN CRITERIA 


In analyzing the research needs and issues to be addressed in the various 
facilities being contemplated, the following factors were determined to 
be common basic design requirements; 

a) Ease of changing functional layout of equipment. This implies both 
change of individual equipment within an area and also shifting of entire 
modules to different locations in the simulator. 

b) Changes to seating arrangements such as location and spacing whereby 
various crew complements can be easily accommodated within the cab. 

c) Cooling required for high density electronics regardless of the 
individual units or clusters of units. 

d) Electrical power for basic equipment needs as well as panel lighting. 

e) Both ARINC 429 and MIL-STD-1 553B data buses for computer interface to 
various displays and controls. 

f) Maximum safety of occupants in the event of a smoke or fire emergency 
or malfunction of motion base system including smoke detectors, 
temperature warning and satisfactory egress methods. Automatic release 
of a fire retardant gas into an area where a warning has been detected 
should be included. 
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g) Environmental conditioning that provides clean, filtered, and 
temperature controlled air. 

h) Easy access to the rear of equipment through combination of hinged 
panels and removable shell panels. Maximum maintenance capability and 
minimum down time because of basic equipment malfunctions must be 
provided. 

i) Special considerations must be given to items not normally found in a 
cab such as television cameras and devices for accepting physiological 
inputs such as heart rate, breathing rate, eye point-of-regard and other 
physiological measures. 

j) Voice communications including ATC interface, crew intercom, test 
conductor private line to other observers, and maintenance intercom. 

k) Emergency system cutoffs located where access is unrestricted in the 
event of a major electrical or hydraulic failure. Automatic activation 
of separately wired emergency lighting. 

l) Consideration must be given to including auxiliary hardware for 
overall realism such as coffee cup holders, trays, map lights, oxygen 
masks, trim detail, carpets. 

4.2.3 HARDWARE INTERFACE 

The use of the digital data bus concept will provide maximum flexibility 
and best growth potential for new and advanced systems. This concept is 
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based upon the serial transmission of data between different subsystems 
using a digital data transmission means. Adding or deleting systems 
becomes more of a software modification task rather than an extensive 
hardware change. There are, however, two standards ARINC 429 (or ARINC 
453) and MIL-STD-1553B, both of which should be available for use by 
components of the simulator. Except for the flight station control 
panel, certain complex functions such as inertial navigation or automatic 
flight controls may be entirely software simulated. 

To achieve this maximum flexibility, the simulator should be able to 
accommodate four possible configurations: 

a) Functional simulation of flight station control units having 
discretes, A/D, D/A, S/D, D/S input/output capability. The avionics 
system itself would be entirely simulated by a detailed model within the 
host computer, or possibly by a microprocessor. 

b) Interface of an entire avionics subsystem consisting of front control 
panels plus actual avionics equipment with the host computer through the 
use of a TI 990/101 special purpose I/O system. The TI interface would 
provide all processing and conversion of data between the host computer 
and the desired format and form of data to the avionics subsystem. 

c) The avionics controls and systems must be designed with an ARINC 429 
bus Input/output capability. This would necessitate a special interface 
unit which could convert ARINC 429 serial digital data into properly 
formatted parallel data suitable for connection to the host computer. 
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Control, sync and data words, would be generated within the special 
interface. 

d) The avionics front panel controls and associated avionics designed 
with MIL-STD-1553B bus input/output capability. Another interface unit 
would be required here to tie the host computer together with the 
avionics subsystem. 

In the case of the instruments which are bus-compatible, the interface 
hardware can be located outside the flight deck. This is not the case 
for AVE hardware located on the flight deck which requires the various 
discrete, analog and synchro interfaces. Here, the interface hardware 
would best be located in the cab so the number of wires coming from the 
flight deck can be minimized. Also, shorter AVE to interface wiring 
helps to minimize noise pickup and cross coupling to other wiring. 

Not all functions, controls, and switches in the flight station have to 
be fully functional. Minor functions such as "No Smoking" and "Fasten 
Seat Belts" are insignificant electrical loads and would not have to 
actually be a discrete input to the computer. In this case, the switch 
could be present and not wired. Other systems must be carefully analyzed 
to assess the impact of the absence of specific electrical system 
inputs. 

Since the simulator cab must be designed to allow easy and frequent 
changes in the functional and physical characteristics of the systems, 
those systems and functions used over and over again must be ruggedly 
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constructed, whereas other experimental system which are used rarely can 
be significantly less durable. 

4.3 ATC FUNCTION REQUIREMENTS 

Resolution of aircraft/ ATC interface issues requires that the ATC 
function include a high degree of fidelity such as the following: 

a) Aircraft Communications (oral and data bus) 

b) Area model - navigation aids, etc. 

c) Pseudo - pilot function 

d) ATC controller station(s) 

4.3.1 AIRCRAFT COMMUNICATIONS 

In addition to the standard aircraft communications requirement for all 
normal air/ground modes of voice communications, an additional 
requirement exists for simulation of the air/ground data link such as 
provided by the DABS system. This type of data link will require both 
input from the controller and output to the controller's console. A 
discussion of the projected data that will flow over the DABS system is 
given in reference 1. The following data are excerpted from that 
report. 
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4-3.1. 1 DABS Downlink Data 


Figure 4-3 details the aircraft systems which send data to the DABS 
transponder for downlink transmission. Most of these data are required 
once every four seconds (one ATC ground station scan time) . 

From the figure it can be seen that the total data transfer required on a 
once-per-scan basis amounts to less than 160 bits. Actually 136 bits 
will suffice if the proper data arrangement is used. This will require 
two data reply words per scan (one comm B, 56 bit reply, and one comm D, 
112 bit reply). The data transfer can also be handled by one ELM comm D 
reply. 

4.3. 1.2 DABS Uplink Data 

The uplink data from the ground system has a wide variation in data 
rates, some data occurring only once or twice during the entire terminal 
phase while other data occurs once per scan, as shown in Figure 4-4. 

4-3- 1.3 Intra-Aircraft Data Requirements 

Figure 4-5 lists the intra-aircraft flow of data and its origins and 
destinations. Examination of ARINC 429 and other ARINC specifications 
reveals that most applications can be accommodated by the low speed ARINC 
bus with very few needing the high speed ARINC version. 
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UPDATE 

WORD 

TYPE 


PARAMETER 

ORIGIN 

• DESTINATION 

RATE 

LENGTH 

MESSAGE 

REMARKS 

Altitude 

DADS 

ATC Display, Conflict Cmptr. 

1/SCAN 

16 bit 

Surveillance 


Ident. 

Acft. Wiring 

ATC Display, ATC Cmptr. 

1/SCAN 

24 bif 

Surveillance 


Pilot Acknowledge 

Pilot Action 

ATC Display, ATC Cmptr. 

1/SCAN 

1 bit 

Surveillance 


Sys. Status 

BIT 

Info. Display, ATC Cmptr. 

1/SCAN 

3 bif 

Comm. B 


A/C Capability 

Acft. Wiring 

Info. Display, ATC Cmptr. 

1/initial 

7-10 bit 

Comm. B 

Includes RNAV 


Contact 



4-0 NAV, CDTI 

Baroset 

Inst. Sys. 

ATC Cmptr. 

4/Min. 

9 bit 

Comm. B 

BCAS notation 

Position 

Fit. Mgmt. Sys. 

ATC Cmptr., Conflict Cmptr. 

1/SCAN 

33 bit 

Comm. B 


Airspeed 

DADS 

ATC, ATC Display 

1/SCAN 

7 bit 

Part of Comm. B 


Track 

INS/FMC 

Conflict Cmptr. 

1/SCAN 

7 bit 

Port of Comm. B 


Heading 

INS (IRS) 

Conflict Cmptr. 

1/SCAN 

7 bit 

Part of Comm. B 


Roll 

IRS 

Conflict Cmptr. 

1/SCAN 

6 bit 

Port of Comm. B 


Wind 

IRS/FMC 

Windshear Cmptr., ATIS 

1/SCAN 

10 bit 

Part of Comm. B 



FMC 

Info. Display, Traffic 

1 (On Req.) 

0-250 bit 

ELM, Comm. D 

Includes waypoints. 



Sequence 




ETO, and vertical 

Route Change Req. 

Pilot Action 

Info. Display 

1/Req, 

0-250 bit 

ELM, Comm. D 

profile for 4D NAV 

Clearance Req. 

Pilot Action 

Info. Display 

1/Req. 

2 bit 

Comm. B 


Trk. Change 

FMC 

Conflict Cmptr. 

1/SCAN 

9 bit 

Comm. B 


Emerg. Declare 

Pilot Action 

Info. Display, Traffic 
Sequence, ATC Display 

1/Req. 

5-10 bit 

Surveillance 

Includes descrip- 
tion of emergency, 
aircraft, medical. 







etc. 

IFR/VFR 

Pilot Action 


1 Initial 

1 bit 

Surveillance 




Contact 




Climb Rate 

DADS 

Conflict Cmptr. 

1/SCAN 

10 bit 

Comm. B 


Ground Speed 

IRS 

Conflict Cmptr., ATIS 

1/SCAN 

9 bit 

Comm. B 


Unreported or 
Unusual Weather 

Pilot Action 

ATC Cmptr., ATIS 

1/Event 

5-20 bit 

Comm . B 

As events occur. 


Note: All Comm. B replies required on a once/scan basis could be condensed Into one, two-segment ELM Comm. D reply or one 
Comm. B and one Comm. D reply. 


FIGURE 4-3 DABS DOWNLINK DATA 
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PARAMETER 

DESTINATION/llSE 

WHEN TRANSMITTED 

Attitude Echo (ALEC) 

Cross Check Ait. Rpiing 

Each Surv. Int err. 

Master Time 

Synchronization 

Initial Contact 

A/C Position Est. with Variance 

FMC - Cross Check A/C Navigation 


Comm. Freq. Assign. 

Int. Comm. - Set Comm. Freq. 

On Contoct/Freq . Chrvg . 

ATIS & Terminal Info. 



Flight Rules 

Info. Display (ATIS) 

Initial Contoct/Prior to Final Appr. 

Ceiling 

Info. Display (ATIS) 

Initial Contoct/Prior to Final Appr. 

Visibility 

Info. Display (ATIS) 

Initial Contact/Prior to Final Appr. 

Altimeter Setting 

Info. Display (ATIS) 

Initial Contact/Prior to Final Appr. 

Active Runway/Rnwy. Assign 

Info. Display (ATIS) 

Initial Contact/Prior to Final Appr. 

Runway Conditions 

Info. Display (ATIS) 

Initial Contact/Prior to Final Appr. 

Surface Winds (At Several Locations 

ATIS & Shear Computation & Display 

Initial Contact/Prior to & During 

Including Rwy. Threshold) 


Final Appr. 

Wind at Approach Alt. 

Shear Comp. & Display 

Prior to Final Appr. 

Wind Profile @ 3000 Ft. Intervals 

FMC (4-D NAV Planning) 

Initial Contact - Entrances to 

with Time of Data Collection 


Term Area, Start of Descent 

RVR & Landing Rules in Effect 

Info. Display 

Initial Contact/At Start of Final Appr. 

Vortex Advisory 

Info. Display 

Prior to Final Appr. 

Windshear Description 

Windshear Comp/Display 

On Final Appr. 

MSAW Warning 

EHSI Display 

On Initial Contact 

T.O. & Landing Clearance 

Pilot Display 

As Appropriate 

Rwy. Turnoff Assignment 

Info. Display 

On Landing 

Route Infb./Control 



Route Assignment, Up to Seven 

FMC - Info. Display 

On Initial Contact 

Waypoints with T.O.A... fer Each 


Course Assignment 

FMC, Pilot Display 

On Contact 

(If Different from Star) 


Metering Fix Time 

FMC - Info. Display 

On Initial Contact 

Route Changes 

FMC - Info. Display 

As Needed or Req. by Pitot 

Approach to T.O. or Approach to Final 

FMC - Info. Display 

Prior to Final or T.O. 

Threshold Time 


On Final Approach 

Weather on Route 

Info. Display 

After Route is Established or Changed. 

Visibility 



Clouds 



Wind at Each Waypoint or Each Leg 



Severe Weather 

FMC - Pilot Disploy 

As occurance, and Updated as Storms Move. 

Location 

Extent 



Gradients 



Severity 



Special Hazards 
Traffic & CDTI 



Expected Traffic in Flow 

Info. Display 

After Initial Contact or When Change Occurs. 

ID's 

Info. Display 

After Initial Contact or When Change Occurs. 

Landing Sequence 

Info. Display 

After initial Contact or When Change Occurs 


FIGURE 4-4 DABS UPLINK DATA 
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PARAMETER 


DESTINATION/USE 


WHEN TRANSMITTED 


Traffic * CDTI (Cant'd.) 

Position of Each 
Altitude of Each 

Speed <£ Direction of Flight for Each 
Vertical Speed 
Roll Angle 
VFR Traffic 


Direction of Flight 
Intentions (If Known) 
Projected Encounter Aircraft 
ID 

Time to Encounter 
REL Direction 
REL Alt. Assigned 
Range to A/C 
Response Assign. 

Position, etc. (CDTI Info.) 
If Not Already Sent 

Conflict Alert 

Projected Best Action 


CDTI & Info. Oisplcy 
CDTI & Info. Display 
CDTI & Info. Display 
CDTI <& Info. Display 
Info. Display 

Collision Avoidance Warning and Display 

Info. Display 

C A Display & FMC 

C A Display & FMC 

CA Display & FMC 

CA Display & FMC 

CA Display & FMC 

CA Display & FMC 

C A Display 

Pilot EADI or EHSI or C A Display 


1/SCAN/Aircraft 
1/S C AN/A i re raft 
1/5 CAN/A i rc ra ft 
1/SCAN/Aircraft 
1/SCAN/Aircraft 
1/SCAN/Aircraft 
1/SCAN/Aircroft 
1/SCAN/Aircraft 
1/SCAN/Aircraft 
1/Aircroft 

On Oceurance, then 1/SCAN 

On Oceurance 

1/SCAN 

1/SCAN 

1/SCAN 

1/SCAN 

1/SCAN 

1/SCAN 

On Oceurance 
As Determined 


Ground Speed or Airspeed 
Altitude 

Direction (Hdg. & Track) 

Next Leg on Release 

Airport Surface Display 
Information 

Taxi Instructions: 

Taxiway route, hold short, 
proceed, other aircraft 
direction, location, 
gate assignment 


Pilot Display & FMC 
Pilot Display & FMC 
Pilot Display & FMC 
Pilot Display & FMC 
Pilot Display, Info. Display’ 

Pilot Display, Info. Display 


As Required by ATCS 
As Chng. needed. 

As Chng. needed. 

As Chng. needed. 

A* Chng. needed. 

Prior to final approach or 
during final approach. 

During landing, during taxi 
as required. 
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SYSTEM 

DATA IN 

ORIGIN 

DATA OUT 

DESTINATION 

• 

SIMULATOR 
BUS NEED 

VHP Comm 

Desired Freq. 

Integrated 
Comm. Control 

Freq Tuned 

1. Integrated 
Comm. Control 

2. Multifunction 
Display 

Input/Output 

HP Comm 

Desired Freq. 

Integrated 
Comm. Control 

Freq Tuned 

1. Integrated 
Comm. Control 

2. Multifunction 
Display 

Input/Output 

SELCAL 



Call 

Annunciation 

Integrated 
Comm. Control 

Output 

Autoflight System 

Attitude, Hdg. 
Air Data 
Steering Data 

IRS 

DADC 

PMS 

MLS 

GPS 

Status 
Failures 
Sys Vam 

1. Multifunction 
Display 

2. AIDS 

Output Only 

MLS 



Deviation, 

Distance 

Auto Plight Sys 
PMS 

None 

Laser IRS 
(ARXNC 704) 

Initial Pos* 
Air Data 

FMC 

DADC 

Present Pos. 
Attitude 
Heading 
Gnd Track 
Gnd Speed 

PMS, DABS 
Autoflt Sys, 
EPIS, DABS 
FMS 

Output to 
EFIS Only 

Radar Altimeter 



Altitude, 

Validity 

FMS, EFIS, 
Autoflt System 

Output to 
EPIS Only 

Vx Radar 

Tilt, Rng 
Attitude 

Integrated 

Control 

IRS 

Digitized 

Video 

EFIS, 

Radar Ind (Option) 

Input/Output 

DADC 



Air Data 
Validity 

PMS 

EPIS 

IRS 

DABS 

Autoflt Sys 
Aids 

Output to 
EFIS Only 

FMS 

(ARI3TC 702) 

Position 
Velocities f 
Validity 
Air Data 

Altitude 
Vaypoints ,et c . 

Approach 
Deviation 
Position Est., 
Alt,, etc. 

IRS, GPS 
DADC 

Radio Alt. 
Integrated 
Control S ys . , 
DABS 

MLS 

DABS 

Steering Data 

Steering Data 
Dev., Desired 
Fit Path, etc. 
Vaypoint Data 
Nav Data, Etc. 
Initial Pos, Time 
Position, Fit 
Path, Speed, etc. 
Status 

Autoflt Sys 
EPIS 

Multifunction 
Display 
GPS, IRS 
DABS 

AIDS 

Input from 
Int. Cont. 
Sys. 

Output to 
EPIS 4 MPD 

EPIS 

(ARXNC 6 00) 

Display 
Inf orroa ti on 
(See Source 
. System) 

DADC 

PMS 

IRS 

MLS 

Autaflt Sys 
Radio Alt 

Status 

AIDS 

Input 

CAS Computer 

Traffic Data 
A/C Velocity, 
Position, 

Planned Pit Path 

DABS 

FMS 

IRS 

GPS 

Conflict Alert, 
Avoidance Commands, 
Traffic Display 
Inf orma ti on 

EFIS, 

Multlf unc tion 
Display 

Output 

Multifunction 

Display 

See Originating 
Systems 


Status 

■1 

Input 

DABS 

See DABS 
Downlink Data 


See DABS 


None 

GPS 



Position (3 Axis) 
Velocity (3 Axis) 

E 



FIGURE 4-5 INTRA -AIRCRAFT DATA FLOW 
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4.3.2 AREA MODEL 


The area model must provide all of the necessary ATC environmental 
elements in the area of interest. The advanced ATC 
computer/communications network that includes systems that will be in 
place in the future should be considered as functions that must be 
included in this model. This would include a system such as ATARS for 
traffic control and fully coordinated BCAS and DABS. An ATS system will 
probably monitor and advise transponder equipped aircraft at some low 
density airports. Many other communication, control and navigation 
systems will remain in use or be in development and must be integrated 
into a coordinated model. 

The MOTAS model that is being developed at NASA LaRC is an example of a 
flexible and totally integrated system that will provide the capability 
to support operating system research in the terminal area. 


4.3.3 PSEUDO - PILOT FUNCTION 

The full traffic load for the controller must be provided by pseudo- 
pilot functions. These functions must be capable of flying a designated 
flight plan that can be altered by ATC controller input. The controllers 
should not be able to detect any difference between simulated cockpits 
and the pseudo-pilot functions. This will require that the pseudo-pilot 
functions be capable of responding to verbal instructions from the 
controller and initiate required verbal transmissions. 
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4.3.4 ATC CONTROLLER STATION 


The ATC controller station must have a computer graphics system with the 
capability to operate in all modes that will be required by the 
controller to perform the procedures under investigation. In addition, 
the ATARS system may require additional input/output devices for the 
console. Both hardware and software must have a high degree of 
flexibility to adapt to the developing concept of the functional 
responsibilities of the ATC controller in the 1990s. 

The minimum ATC function must have full aircraft communications 
capability as described previously; however, the mechanization of the 
function may be reduced to a function of the test conductor's console. 
Any navigation aids required for the simulation must be supported. 
Traffic can be totally under computer control, if required, and there 
would be no requirement for pseudo-pilot functions that would extend 
beyond data required for the CDTI display or the visual system. The 
controller's station and display function would not be required. 


4.4 COMPUTER COMPLEX 
4.4.1 HARDWARE SYSTEM 

Functionally, the computer complex is the heart of the ACRS since it 
provides the means by which overall operation of the facility is 
implemented and controlled. As the term is used here, the computer 
complex includes all computers employed within the ACRS, their 
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peripherals, the software system and the I/O system. An overview of the 
computer complex and its interface with the remaining elements of the 
ACRS was shown earlier in Figure 4-1. 

4.4. 1.1 Utilization 

Utilization of the computer complex falls into two primary categories — 
simulation and software development. Additional secondary applications 
may be identified at a later date. While the primary uses will be common 
to all versions of the ACRS, secondary applications of the computer 
complex, if any, may well be peculiar to each facility. Reduction of 
special-purpose test data is an example of a unique requirement at one 
facility that would represent a secondary, though important, function of 
its computer complex. Another example might be the storage of research, 
training or maintenance records using the computer complex resources at 
another facility. 

In its role of supporting flight research and training activities, the 
computer complex must generate the basic aircraft/systems simulation and 
must provide the means by which facility personnel can exercise control 
over simulator operation. It must be recognized, of course, that the 
configuration of the ACRS will never be finalized but will continue to 
change to satisfy new requirements. In its software development role, 
the computer complex must therefore provide all tools necessary to 
develop the operational software and firmware required to satisfy both 
current and future research goals. 
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4.4. 1.2 Design Criteria 

The ACRS must be configured to satisfy a variety of research and 
development needs while taking full advantage, where possible, of common 
design concepts and techniques. Functional commonality does not, 
however, require the use of identical hardware or software components. 
In specifying common design parameters for the computer complex, it must 
be realized that different physical machines or networks of machines may 
satisfy the stated requirements. Any one of several acceptable hardware 
implementations may thus be selected for use in a particular ACRS without 
violating the common design concept and without eliminating the many 
advantages inherent in such an approach. 

A number of basic requirements must be satisfied by the computer complex, 
regardless of the specific physical implementation chosen. These include 
the following: 

a) The computer complex must be capable of providing a high fidelity 
simulation of the desired aircraft configuration (the airframe plus its 
systems) along with any appropriate external effects. 

b) It must provide the hardware and software necessary to allow facility 
personnel to specify a given test situation, control its execution and 
evaluate the results. 
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c) It must include all hardware and software components required to 
support efficient software development activities. In some versions of 
the ACRS, the computer complex must be capable of supporting simultaneous 
flight simulation and software development operations. 

d) Sufficient computational power and speed must be available to allow 
the necessary simulation and testing tasks to be accomplished in 
real-time. 

e) It must implement an architecture which provides the flexibility 
necessary to allow the ACRS to be easily configured to satisfy a wide 
variety of current investigative needs. 

f) Sufficient computer resources must be available to accommodate future 
expansion in response to changing research requirements. 

g) It must allow the transfer of experiments and simulation packages 
(both hardware and software) between facilities. 

h) Its design must include consideration of features to minimize life 
cycle cost associated with the implementation, operation and maintenance 
of the facility. 

i) Its design must be highly modularized to allow portions of the design 
to be added, deleted, modified or otherwise utilized as required without 
adversely affecting overall operation of the ACRS. 
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4.4. 1.3 System Architecture 


While a number of basic design decisions affecting the overall 
flexibility and power of the ACRS must be made, few have the potential 
impact of the one concerning definition of the computer complex 
architecture. Selection of a non-optimum architecture initially would 
have serious implications on the flexibility of the facility and its 
ability to respond to changing needs and research goals. 

This decision involves selection of one of the two basic architectural 
approaches outlined in Figure 4-6. The first of these, the centralized 
architecture, makes use of a single, relatively large host computer to 
provide all computational functions for the ACRS. The second, generally 
referred to as a distributed architecture, uses one or more mid-sized 
host computers in a network with a number of smaller computers 
(minicomputers and microcomputers) distributed throughout the facility. 

Analysis of the requirements indicates that the computer complex for the 
ACRS should be configured as a network of distributed computers. This 
decision is based upon consideration of the following factors: 



HOST COMPUTER 
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TO OTHER ACRS ELEMENTS 


a. CENTRALIZED ARCHITURE 



V 
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TO OTHER ACRS ELEMENTS 


b. DISTRIBUTED ARCHITECTURE 


Figure 4-6 • ARCHITECTURAL APPROACHES TO THE COMPUTER COMPLEX 
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a) Computational power and flexibility - The computer complex must 
obviously possess the basic characteristics necessary to perform in 
real-time the multitude of computations involved in providing the 
simulation, control and evaluation functions basic to its use as a 
research and development tool. In addition, it must be capable of 
simultaneous use for software development purposes. While various large 
computer systems may be capable of satisfying the ACRS requirements 
insofar as computational power is concerned, a network of smaller 
machines provides a much more flexible approach. With a network, the 
distribution of the computational burden among the various computers can 
easily be modified in response to changing requirements. 

b) Operational efficiency - Every effort must be made to ensure that the 
functions required for proper operation of the ACRS are accomplished in 
the most efficient manner possible. This implies that the physical flow 
of information within the facility must be minimized. The use of a 
network of computers allows the computational power to be distributed 
throughout the facility so that data can be operated upon near its source 
(or its destination, as appropriate) . The result can be a reduction in 
the number of internal data transfers required with a corresponding 
increase in overall operational efficiency. 

c) Expansion of computational capability — While closely related to the 
question of overall flexibility, this factor more specifically addresses 
the potential for expansion of the computer complex to satisfy future 
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requirements which cannot be fully anticipated at the present time. A 
properly structured network of computers is, by its very nature, easily 
expandable to provide additional computational capability. Expansion of 
a centralized complex, once the large machine has been saturated, can be 
very expensive in terms of both time and money. 

d) Life cycle costs - A network of medium and small-sized computers can, 
if structured correctly, provide overall capability equivalent to that of 
a single large machine at a fraction of the cost. Additional savings can 
be realized as a result of the low level of maintenance normally required 
by these smaller machines as opposed to that involved in the day-to-day 
operation of a large computer system- 

e) System reliability - The medium and small-sized computers available 
today are extremely reliable devices, as are their peripherals. Aside 
from considerations of the reliability of individual system modules, 
however, operational reliability and availability of the ACRS as a whole 
is the important concern. The relatively small cost at which computing 
power can be purchased today in the form of midi-, mini- and 
microcomputers implies that a network of these machines can be 
economically configured to possess a considerable amount of spare 
processing capability. In some cases, the additional capability 
available may be such that, in the event of failure of one of the network 
members, its vital processing tasks can be distributed among the 
remaining members in a predetermined fashion such that normal operation 
of the ACRS can continue while the failed unit is being repaired. 
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All factors considered, implementation of a network of computers offers 
the most efficient and cost effective solution to the processing needs of 
the ACRS. Again, it should be stressed that sufficient latitude exists 
within the overall concept to allow any of several hardware/sof tware 
configurations to be selected for implementation within the various 
ACRS's while still retaining the many advantages of functional 
commonality. 

4.4. 1.4 System Characteristics 

Bearing in mind that the desired goal is functional commonality, the 
primary concern at this time is to identify the characteristics which the 
computer complex must possess in order to provide the required 
operational capability. As stated earlier, actual physical 
implementation can assume a number of forms without compromising the 
overall concept of functional commonality and interchangeability. This 
initial effort is thus directed toward specification of overall design 
requirements and is not intended to identify specific hardware and 
software components. 

Specification of the design requirements for the computer complex 
obviously involves many considerations, some of which may tend to be 
incompatible. While definition of certain non-controversial parameters 
may be easily accomplished, the establishment of others will involve 
detailed analysis of design trade-offs. When design conflicts do occur, 
the decision criteria must be prioritized as 1) the capability to satisfy 
specific operational requirements for a given ACRS, 2) flexibility to 
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respond to new and expanded tasks and, 3) functional commonality among 
similar facilities. 

The following discussion identifies some of the more significant design 
considerations relative to the computer complex hardware: 

a) A network architecture has been specified in which the total 
computational burden of the ACRS is distributed among one or more host 
computers and a number of smaller peripheral computers. For a number of 
reasons (reduction of life cycle costs and achievement of functional 
commonality being the primary ones), the majority of the software 
included within the host computer will be written in an HOL. The host 
computer must therefore be one which possesses the operational 
characteristics consistent with execution of a large volume of HOL code 
in real-time. This requires features which go far beyond pure 
computational speed and implies an internal computer architecture 
designed primarily to achieve efficient execution of HOL software. A 
corollary implication is that the support software used to develop the 
applications programs must have been designed to generate extremely 
efficient machine language code from the HOL statements. A highly 
desirable feature is the capability to mix HOL and assembly language code 
when appropriate. 

The peripheral computers used within the ACRS should include both 
minicomputers and microcomputers. The minicomputers deemed suitable for 
the ACRS must be capable of executing at least modest amounts of HOL code 
in real-time and thus must be primarily programmed in an HOL for this 
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application. Microcomputers, on the other hand, are generally not 
designed to execute HOL code in real-time. As a result, the majority of 
the software provided for these machines should be written in assembly 
language form. The architecture of the microcomputers selected for the 
ACRS must allow for extremely efficient execution of assembly language 
code in order to satisfy the real-time operational requirements. 

b) The host computer should have a word length of at least 24 bits. 
While many simulation tasks can be adequately accomplished using a 
machine with a shorter word length, simulation of certain types of 
systems or effects demands the longer word in order to efficiently 
achieve the required accuracy and precision. A specific example is the 
simulation of an inertial navigation system in which more than 16 bits 
are necessary in order to provide a sufficiently accurate simulation of 
operational performance. 

c) The ability to efficiently operate upon individual bits and bytes 
within words, as well as upon the words themselves is a requirement. 
Operational efficiency demands that the amount of data flow among the 
computers within the network and between the computers and the remaining 
elements of the ACRS be minimized. In this context, bit manipulation 
capability is vital in order to accommodate the relatively large number 
of discrete signals which must be processed during operation of the 
facility. Similarly, the ability to efficiently handle information in 
byte form must facilitate accomplishment of the required digital 
communication tasks. 
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d) All machines within the computer complex must be capable of extremely 
efficient I/O transfers. The ability to accomplish both 
program-controlled and direct memory access-type I/O operations is 
desirable so that the appropriate mode can be selected for each specific 
application, the primary criteria being efficiency. The impact of I/O 
operations upon normal software execution must be considered along with 
the requirements of pure transfer speed. 

e) Closely related to the need for efficient I/O capability is the 
requirement that each computer possess a flexible interrupt structure. 
Many functions within the ACRS must be accomplished on an as-needed basis 
using interrupt-driven software. Even the scheduled repetitive tasks 
must be initiated as a result of various levels of system interrupts. 
Operational efficiency thus demands that the computers respond to and 
service these interrupts quickly and with as little software overhead as 
possible. 

f) While not a requirement, a number of significant advantages can be 
realized if at least some of the machines included within the computer 
complex belong to a family of processors. Ideally, the peripheral 
computers should possess a certain level of hardware and software 
compatibility, if for no reason other than to reduce the investment in 
the necessary support systems. As a practical example of the application 
of this concept, the following possible computer complex implementation 
plan should be considered. The host computer is a VAX-11/780. The 
peripheral computers all belong to the family of software-compatible 
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TI-990 processors and include 990/12 and 990/10 minicomputers along with 
990/4, 990/5 and 990/101 microcomputers. If required, special-purpose 
computers can be designed around the TMS/9900 microprocessor. 
Development of software for any of the peripheral computers can thus be 
accomplished using a single software development system. 

g) The computer complex should include all peripherals required to 
support both simulator operation and software development activites. 
Specific peripherals provided will include magnetic disc units, magnetic 
tape units, line printers, card readers and CRT display terminals. 

4.4. 1.5 Life Cycle Cost Considerations 

While the initial design, procurement and installation of the computer 
complex represents a significant investment, it is in reality only a 
relatively minor portion of the total life cycle cost. Decisions made 
during this initial phase can, however, dramatically affect the ultimate 
cost, either favorably or unfavorably. Design of the computer complex 
should thus be accomplished with due regard to all factors which 
contribute to life cycle cost and should incorporate features to reduce 
this to the lowest level consistent with achievement of the research 
goals. 

Specific areas which must be addressed during the design phase include: 
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a) Fabrication, installation and checkout — Modular design techniques, 
coupled with a distributed architecture, must be exploited to minimize 
the effort involved in fabricating the system modules and integrating 
them into a functioning ACRS. 

b) Reliability — State-of-the-art digital components and systems must be 
used throughout to ensure maximum operational reliability. 

c) Maintainability — The ease with which maintenance can be accomplished 
at both the module and the facility level must be stressed. Adequate 
documentation must be provided to aid required maintenance actions. 
Comprehensive diagnostics must be provided as appropriate, with emphasis 
upon use of test features built into the various modules and systems. 
The objective must be to configure a simulator which can be maintained 
with minimum reliance upon outside vendor service. An adequate level of 
spares must be identified so that failed items critical to operation of 
the ACRS can be quickly replaced to return the simulator to operational 
status. 

d) Expansion — The ACRS must be designed with expansion in mind. The 
flexibility to satisfy unanticipated near-term changes must be provided 
along with the ability to easily accommodate major expansion in the 
future. 

4.4. 1.6 Hardware System Design Tasks 

The following tasks must be accomplished in order to design the computer 
complex hardware system: 
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a) Establish overall design requirements for the computer complex 
hardware system. 

b) Identify the physical requirements imposed by the computer complex 
hardware on the ACRS facility, including consideration of related safety 
aspects. 

c) Design the computer complex hardware architecture. 

d) For each ACRS, identify the computers to be used as the host and 
peripheral processors. Specify the manner in which they are to be 
interfaced with the remaining functional elements of the ACRS. 

e) Identify the peripherals required to support both simulation and 
software development activities and provide interfaces with the 
appropriate computers. 

f) Provide for installation of AVE components as appropriate to the 
research goals of a given ACRS. 

g) Generate the documentation required to establish configuration control 
of the computer complex hardware and to facilitate its maintenance. 

4.4.2 SOFTWARE SYSTEM 

As noted earlier, the ACRS should be driven by a multi-processor computer 
complex. The total software system should be distributed among the host 
and the various peripheral computers. An overview of the distribution of 
the software is shown in Figure 4-7. 
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FIGURE 4-7 . SOFTWARE DISTRIBUTION WITHIN THE ACRS 
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Overall operation of the facility should be under control of the host 
computer which should contain the master Executive, the majority of the 
software models and the master I/O control software. Most of the 
peripheral computers should serve primarily as intelligent I/O 

controllers and should contain their own Executive, the necessary I/O 
control and processing routines and, where appropriate, individual 
software models. Transfer of data between each of these peripheral 
computers and the host should occur as necessary. While each peripheral 
computer should function in a semi-autonomous fashion under control of 
its internal software, ultimate control must be exercised by the host. 

In addition to the I/O system, certain types of auxiliary systems should 
contain internal computers. A specific example shown in Figure 4-7 is 
that of the visual system which would generally > be purchased as an 
off-the-shelf entity complete with its own dedicated computer and 
software system. 

Perhaps .no area of the overall design task is more critical to the 
ultimate capability of the ACRS than that which addresses the detailed 
structure of the software system. While all elements must obviously be 
present and properly integrated in order for the faciity to function 
properly, the software system must be recognized as the single element 
which ultimately determines the flexibility and overall utility of the 
ACRS as a research, development and training tool. 
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Given the impact of the software system, extreme care must be exercised 
to ensure that its structure provides both the desired level of 
simulation fidelity and the flexibility to allow the simulation to be 
easily reconfigured and expanded in response to changing requirements. 
Of particular importance, in view of the real-time nature of the problem, 
is assurance that the two basic computer resources — memory and 
processor time — be utilized as efficiently as possible. 

4.4.2. 1 Software System Language 

One of the more fundamental questions which must be addressed during the 
design of the ACRS concerns the particular software language to be used. 
The overriding consideration is obviously the need for real-time 
operation to allow the desired degree of simulation fidelity to be 
achieved. In a simulator dedicated to a particular task (crew training 
for a specific aircraft type, for example), assembly language might well 
be chosen so as to attain maximum efficiency in the execution of the 
resulting software code. In configuring an ACRS for general-purpose 
research use, however, factors beyond mere execution efficiency must be 
taken into account. 

Specific factors which affect selection of the simulation software 
language include: 

a) The need for real-time operation, which implies a high level of 
software execution efficiency. 
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b) The goal of minimum life cycle cost, which requires efficiency of 
software development, documentation and maintenance. 

c) The desire to be able to transport the software from one ACRS to 
another (and thus possibly from one computer to another) with minimum 
rework of the code. 

All factors considered, the desire to achieve maximum commonality among 
various advanced research simulators demands that the simulation software 
be written in a common HOL to the extent practicable. Of the HOL's, 
FORTRAN is the most likely candidate for this common language due to the 
fact that it is supported by essentially every computer system available 
today, including all large mainframe machines, midicomputers and 
minicomputers. 

The evolution of other HOL's should be closely monitored and evaluated 
for possible future simulation applications. Of particular interest are 
the HOL's being considered for possible airborne applications, since the 
use of a language compatible with advanced AVE computers would obviously 
be advantageous to the ACRS. At present, however, no language can rival 
FORTRAN for general availabiity or applicability. 

While the vast majority of the simulation software should be written in a 
common HOL, certain modules should be coded in assembly language. In 
particular, certain I/O routines should be written in assembly language 
so as to maximize the efficiency with which the necessary I/O operations 
can be accomplished by the peripheral computers. As will be discussed 
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later, the I/O system should employ distributed microprocessors to 
perform many of the computational tasks associated with the actual 
scaling, formatting and transfer of the simulator data. Microprocessors 
are not, in general, efficient HOL machines and are usually programmed at 
the assembly language level. 

The simulation software system should thus be written, for the most part, 
in a common HOL so as to maximize flexibility while minimizing life cycle 
costs. Where appropriate, however, assembly language routines should be 
used to achieve the desired operational efficiency, the objective being 
an optimum mix of HOL and assembly language code that produces the most 
efficient and flexible simulation possible, while retaining the highest 
possible level of software commonality and transportability. 


4. 4* 2. 2 Host Computer Software Structure 

The host computer software should execute under control of an Executive 
routine which will: 

a) Perform all required initialization functions. 

b) Issue calls to the various simulation models. 

c) Perform all necessary software system bookkeeping. 


d) Control the I/O system 



A simple flowchart of a typical Executive is shown in Figure 4-8. Upon 
start-up, this routine issues the commands necessary to initialize the 
simulator, including the software, the I/O system, all test/control 
consoles and any other peripheral devices or systems. Once 
initialization has been completed, the Executive waits for the first 
interrupt from the RTC. Periodic receipt of the RTC interrupt triggers 
the Executive to issue commands to control the I/O system and to execute 
the appropriate foreground and background models. Once all scheduled 
tasks have been accomplished, the software sits in a loop awaiting the 
next RTC interrupt. 

The simulation software system should include a number of individual 
routines (models) designed to simulate the functioning of various 
aircraft systems as well as the effects of the external environment. 

Each of the models must be repetitively executed at a rate which will 
cause the simulated system or effect to appear to be occurring in 
real-time analog fashion. The rate at which each model must be executed 
so as to achieve this desired effect is obviously a function of many 
factors, and not all models will require execution at the same rate. A 
critical phase of the design of the overall software system thus involves 
determining the optimum iteration rate for each model and structuring the 
Executive to call each one correctly. 
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FIGURE 4-8 . TYPICAL SIMULATION EXECUTIVE ROUTINE 
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An extremely flexible way to accomplish the scheduled execution of the 
various models is to set up a calling structure similar to the one shown 
in Figure 4-9. At each level, a table of pointers exists into which the 
transfer vectors (addresses) of individual models can be placed. These 
pointers thus determine the rate at which each model is iterated. 

In the specific example shown, the RTC interrupt is assumed to occur 
every 16.7 msec, such that an individual software model can be executed 
at a maximum rate of 60 times per second. This basic iteration rate is 
sub-divided into 20/sec, 10/sec, 5/sec and 1/sec slots. During each RTC 
interval all 60/sec models are executed as are the models from one each 
of the 20/sec, 10/sec, 5/sec and 1/sec slots. During the typical RTC 
interval illustrated by means of the arrows in Figure 4-9, for example, 
the execution of models would proceed as follows: 

a) All 60/sec models in leg 60S1. 

b) All 20/sec models in leg 20S3. 

c) All 10/sec models in leg 10S5. 

d) All 5/sec models in leg 5S10. 

e) All 1/sec models in leg 1S49. 
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The example of Figure 4-9 is included merely to illustrate an efficient 
and flexible technique by which the various models can be called. The 
actual model execution sequence and timing implemented within a given 
simulator will obviously be a function of the peculiar needs of that 
simulator and can be controlled simply by selecting the appropriate RTC 
interrupt timing and transfer vector structure. 

The advantages of the model calling mechanism outlined above include: 

a) Ability to iterate a given model at the rate appropriate for the 
specific system or effect being simulated. 

b) Flexibiity to add additional models simply by inserting their transfer 
vectors in the appropriate time slots. 

c) Flexibility to delete a model or to temporarily suspend its execution 
simply by removing its transfer vector from the calling sequence. 

As indicated in Figure 4-9, individual models can be called for execution 
in either the foreground or the background as appropriate. Foreground 
models include those which must be executed on a very carefully 
controlled cyclic basis if the fidelity of the simulation is to be 
adequately maintained. Background models generally run at a somewhat 
slower rate than do those in the foreground and execute on a 
time-available basis. That is, execution of background models can be 
delayed if necessary due to a temporary lack of sufficient processor 
time . 


- 71 - 



While the technique just described can be used to call models for 
execution on a cyclic basis, various functions within the software system 
will require execution on a totally asynchronous basis in response to a 
variety of interrupts. In this case, the normal execution sequence of 
the software system will be suspended long enough to provide the service 
demanded by the source of the interrupt. 

Use of the ACRS for either research or training purposes requires that a 
high degree of fidelity be maintained within the overall simulation. As 
mentioned earlier, simulation of the various systems involves executing 
appropriate software models at carefully controlled rates so that the 
resulting effects will appear analog in nature. In actual operation, 
situations can arise in which the amount of processing required by the 
simulation software (the models, I/O and other functions) per unit time 
exceeds the amount of CPU time available. The simulation is then said to 
have "run out-of-time" and thus can no longer execute in true real-time. 

In such a situation, two alternatives are available to the software 
designer. He can either: 

a) Allow the simulation to continue running with attendant loss of 
fidelity, or 

b) Halt the simulation on the basis of pre-determined out- of-time 
criteria. 

Of these two approaches to simulation design, the second is preferable. 
This is especially true in the research/training environment where 
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important results might well be masked or distorted by even a relatively 
small loss of simulation fidelity. 

The actual out-of-time criteria used to terminate a given simulation is 
obviously a function of the specific situation in which the simulation is 
being applied. In a sophisticated mission-oriented crew training 
simulator, for example, the following out-of-time criteria is appropriate 
— the simulation is immediately halted if the RTC interrupt for the next 
leg of the foreground processing is received before any models of the 
current leg have been executed. This defines a situation in which the 
execution of the simulation software is lagging to a degree which results 
in unacceptable real-time performance. Background routines can be 
allowed to lag behind progressively without halting the simulation, the 
assumption being that execution of these slower, less important routines 
will eventually catch up and resume at the desired rate. 

4. 4. 2. 3 Peripheral Computer Software Structure 

Structurally, the software system of each peripheral computer will 
parallel that of the host and will include an Executive which can call 
various models for execution in either the foreground or the background 
mode. Peripheral computers will be added to the ACRS as required to 
achieve the desired level of system flexibility and operational 
efficiency. As such, they will serve to relieve the host computer of 
much of the overall computational burden. 
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The primary function of the peripheral computers is to accomplish the I/O 
operations required to link the host computer with the simulator cockpit 
and other elements of the ACRS. Software within the various computers 
would thus be primarily I/O-oriented and would be designed to provide 
appropriate conversion and formatting of the various I/O parameters. 
Specific I/O functions performed by the peripheral computer software 
should include: 

a) Acquisition of parameters in engineering units form from the host 
computer and their conversion to, and output in, the appropriate analog 
or discrete form to the various simulator systems. 

b) Acquisition of raw simulator parameters, conversion of those 

parameters to corresponding engieering-units values and transfer of the 
parameters to the host computer upon request. 

While the peripheral computers should serve primarily as intelligent I/O 
system controllers, the speed and processing power of the modern 

minicomputers and microcomputers that should be used is such that they 
can easily perform additional functions within the overall simulation 
system. In certain cases, software models designed to simulate systems, 
or portions of systems, could be included within the peripheral computers 
to improve the execution efficiency of the overall software ststem. 

As a specific example, consider the case of an autopilot system. For 
purposes of math modeling and simulation, an autopilot can generally be 

divided into two distinct sections — switching logic and control loop 
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computations. While both sections may be included within the same 
software model, considerations of execution efficiency may dictate that 
the two be separated. In order to achieve the desired fidelity of 
simulation, the control loop computations must generally be executed at 
least ten times per second. The switching logic, on the other hand, may 
need to be computed only two times per second in order to provide 
acceptable performance. Execution of the switching logic at a rate of 
ten/sec in this example thus represents a waste of processor time (a 
valuable resource) with attendant loss of efficiency. The optimum 
solution in this case might well be to model the control loop within the 
host computer while performing the switching logic within one of the 
peripheral minicomputers, passing only a few necessary parameters between 
the two. 

One consideration in configuring the overall software system within a 
multi-processor environment is obviously the language (or languages) to 
be used. This problem was addressed earlier with the conclusion being 
that efficient operation of a sophisticated simulation facility requires 
a mix of HOL and assembly language. While the software within the host 
computer and the peripheral minicomputers is envisioned as being written 
primarily in a standard HOL, most of the software within the peripheral 
microcomputers should be in assembly language form. 

Assembly language code should be used with the peripheral microcomputers 
for a variety of reasons, some of which are enumerated below: 
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a) While modern microcomputers do possess considerable processing 
capability, their speed characteristics are generally not compatible with 
execution of HOL code in a real-time environment. 

b) These computers will generally be performing dedicated functions 
related primarily to I/O operations. The associated software should be 
written in assembly language to take full advantage of the particular 
computer's capabilities as implemented by its instruction set. 

c) The software included within these computers should primarily consist 
of common, general purpose routines designed to perform all functions 
associated with I/O operations. These routines should be structured to 
easily accommodate expansion or contraction to adjust to various I/O 
situations without requiring major changes. Once written, they should 
remain essentially unchanged and should be usable in their original form 
in a variety of simulation applications. 

4. 4. 2. 4 Aircraft Systems Software 

Software must be provided to simulate the various aircraft, systems and 
environmental characteristics necessary to accomplish the stated research 
goals. The software should be modularized to facilitate reconfiguration 
of a given ACRS and to allow the various routines to be easily 
transported from one simulation facility to another. The basic routines 
necessary to provide a high fidelity simulation of a modern aircraft 
include, but are not limited to, the following: 
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AIRPLANE FLIGHT ENVIRONMENT 


Ground Handling 
Ground to Air Transition 
Airborne Characteristics 
Airfield Conditions 
Atmospheric Conditions 


NAVIGATION ENVIRONMENT 

Non-directional Beacon 

VHF Omni-range 

DME 

Precision Approach Radar 

ILS & MLS 

Landing Markers 

Airways Markers 

OMEGA 

GPS 


COMMUNICATION SYSTEMS 

HF 

UHF 

VHF 

SELCAL 
UHF SATCGM 
Intercom 
PA 

Voice Recorder 
Data Link 
CDTI 

Integrated Comm Management System 


AIRFRAME SYSTEMS 

Hydraulic 

Electrical 

APU 

Propulsion 
Fuel System 

Electronic Flight Instrument System 
Advanced Integrated Display System 
Cabin Pressurization 
Pneumatic System 
Cabin Air Conditioning 
Ice Protection, Defogging 
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Oxygen System 

Fire Detection and Extinguishing 
CADC/DADC 

Flight Data Recorder 
Caution and Warning System 
Lighting 

Weight and Balance 
Crash Position Indicator 


WEATHER RADAR 


NAVIGATION 

INS 

MHRS 

Attitude System 
Laser IRS 
ADF 

Marker System 

ATC Transponder 

Stand-by Compass 

Radio Altimeter 

VOR/DME/ILS 

MLS 

OMEGA 

GPS 

GPWS 

CAS 


FLIGHT CONTROLS 

Autopilot/Flight Director System 

Flight Management System 

Primary Attitude 

Thrust Management System 

Autothrottle 

Landing Gear & Brake 

Speed Brake 

Flaps/Slats 

Trim 

Yaw Damper 


4. 4.2. 5 External Effects Software 

In addition to providing a simulation of the aircraft and its systems. 
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the AGRS must create a realistic environment of external effects. These 


external effects play a major role in providing the overall realism and 
fidelity needed to achieve the research goals. They include the: 

a) Radio aids and ATC interface 

b) Visual system 

c) Motion system. 

Each of these items requires appropriate software to accomplish, the 
exact form of which should be a function of the manner in which the ACRS 
is to be used. Certain types of research require that the simulator 
cockpit be mounted on a sophisticated 6-DOF motion system so that the 
appropriate motion cues can be provided to the crew. In other areas of 
research -- the interface of large transport aircraft with the projected 
ATC environment, for example — motion may not be required at all. In 
any event, software to simulate the appropriate external conditions must 
be available. 

Radio aids and ATC interface software will simulate the ground portion of 
the applicable guidance and control systems, including provisions for 
interaction between the flight crew and ground personnel as appropriate. 
In cases where interaction with the ATC environment is incidental to the 
research studies being conducted, the radio aids software can be included 
within the host computer. In cases where the ATC interface is the 
primary item of interest, extremely sophisticated software to simulate 
this interface should almost certainly be provided in a peripheral 
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computer devoted primarily to this task. In any event, design of the 
radio aids software should be highly modular so as to be independent of 
the particular computer used. 

A high quality visual system is unsurpassed in providing motion cues to 
the flight crew within a simulator designed for transport aircraft. 
Whether used for advanced research studies, systems development, or crew 
training, a full-task simulator should almost certainly include some type 
of visual system to provide a view of the external scene appropriate to 
the task at hand. With a wide variety of computer-based visual systems 
available, one can be purchased off-the-shelf for essentially any 
application. These systems are normally procured as stand a lone items, 
complete with the necessary computer, software, I/O and displays. The 
software impact of integration of such a system into a specific ACRS 
configuration involves two major areas: 

a) Tailoring of the standard visual system software, if required, to 
satisfy peculiar simulation needs. 

b) Provision of software within the host computer to transfer the 
necessary variables between the host and the visual computer. 

Similarly, a wide variety of simulator motion systems are available 
off-the-shelf. Appropriate motion system hardware can usually be 
purchased to satisfy any particular simulation requirement. A software 
module must be provided within the host computer to generate the 
simulation parameters necessary to drive the specific motion system 
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selected. While the details of this software must be a function of the 


particular motion system being used, a common routine structure can be 
designed. The only difference among ACRS's insofar as the motion system 
software is concerned would thus be the form of the software variables 
which must be provided to drive the individual hardware systems. 

4. 4. 2. 6 Control/Display Software 

The full-task simulator, if properly instrumented, can be used as an 
effective tool for basic research, crew training or systems development 
purposes. If properly designed, the same physical facility may be used 
interchangeably to perform any of these functions as required. In any 
case, one of the keys to effective utilization is the manner in which the 
researchers, instructors and evaluators are allowed to exercise control 
over the facility and to extract information from it. 

In general, the individuals controlling the ACRS will need the ability to 
input certain commands and data parameters into the facility in order to 
establish the desired test conditions. Examples of such inputs include 
simulated system malfunctions, navigation parameters, environmental 
conditions and ATC commands. Conversely, these individuals will require 
real-time access to the various types of information necessary to 
evaluate the progress of the mission or the test being conducted. 

To achieve the highest degree of flexibility, the physical interface 
between the controllers and the ACRS should generally be provided by some 
type of CRT display/multifunction keyboard arrangement. Software should 
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be provided to accept and react to the various input commands and to 
retrieve, format and display requested information. General-purpose 
software drivers should be used to service the CRT displays and 
multifunction keyboards. Where possible, general-purpose data 

retrieval/formatting routines should be provided. In certain cases, 
however, special-purpose software modules are required in order satisfy 
unique testing requirements. 

Like all other software, the control/display package will execute under 
control of the master Executive. In cases involving periodic update of 
displayed information, the software will be executed on the basis of 
scheduled transfer vector calls. Those routines which require 
nonscheduled execution should be interrupt-driven. 

4. 4. 2. 7 Software Life Cycle Cost Considerations 

The true cost of the simulation software system must be computed in the 
context of its overall life cycle. This life cycle cost includes all 

effort expended in maintaining the software during its useful life as 
well as the effort required initially to design, develop and install it. 
Specific actions which can be taken to minimize software life cycle costs 
include: 

a) Use of a standard HOL to the extent practical. 

b) Implementation of a common system structure composed of compact 
software modules. 
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c) Development and sharing of common software packages by ACRS users. 

d) Use of on-line diagnostic/development aids coupled with comprehensive 
configuration control techniques. 

The simulation software system will include a mix of HOL and assembly 
language code. In order to reduce overall software life cycle costs, 
however, the standard HOL should be used to the maximum extent possible. 
Specific cost reductions which can be realized through use of the 
standard HOL include: 

a) Development of the software with minimum expenditure of manhours as a 
result of the coding efficiency achievable with HOL. 

b) Ease of software interpretation and modification. 

c) Generation of the software code by HOL programmers as opposed to use 
of programmers who are experienced in various assembly languages. 

d) The ability to share general simulation routines among various ACRS's 
with only minimum modification as a result of the inherent 
transportability of HOL software. 

Design of the software system should be accomplished using proven 
top-down structured programming techniques. The overall system design 
should be generated by a small team of highly experienced simulation 
software experts that: 

a) Establish the system requirements. 
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b) Plan the overall software structure 


c) Identify and describe specific software modules required, along wih 
their interface parameters. 

d) Coordinate the development of the individual modules and their 
integration into the total software system. 

Once the initial system design has been completed, a larger team of 
programmers can be used to code and develop the individual software 
modules. 

An important factor which can be exploited to reduce life cycle costs is 
the concept of software modularity. While the overall simulation 
software system must be quite large and of necessity very sophisticated, 
it must be composed of compact modules. The structure of the software 
system must be such that individual modules can easily be added, modified 
or deleted as required to satisfy particular simulation situations. 

Use of compact software modules provides numerous benefits. The first of 
these is the relative ease with which the software system can be 
modified, either to expand the simulator's basic research capability or 
to enhance its fidelity. If the overall system has been properly 
structured, desired modifications can be accomplished merely by adding or 
deleting appropriate modules or by modifying existing ones. In either 
case, the necessary changes can be accomplished quickly, easily and with 
minimum disruption of normal simulator operation. 
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A second, and very important, advantage is the inherent flexibility of a 
modular software system. Use of software modules in implementing a 
training simulator designed for a specific aircraft type affords 
significant cost savings over the life of the simulator. These savings 
can be realized even though the basic aircraft configuration can be 
expected to change only slightly over the years. Contrast that 
relatively static situation with the highly dynamic research environment 
in which the ACRS will be used to investigate a variety of advanced 
aircraft/systems configurations, in some cases being completely 
reconfigured from day-to-day. The use of software modularity is 
definitely a requirement for the ACRS in order to achieve the flexibility 
necessary to respond quickly and efficiently to changing research needs 
and goals. 

Finally, use of a software system structure composed of compact modules 
would enhance the development of common software packages and their being 
shared among various simulation facilities. For example, a software 
module simulating an advanced flight control system could be developed by 
members of one ACRS and then implemeted and used at essentially no cost 
by other similar facilities. Various data bases — aerodynamic packages, 
radio aids parameters and environmental packages for example — can be 
easily generated in modular form for sharing among several simulation 
facilities. 
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4. 4. 2. 8 Development Software 


One primary function of the computer complex is to exercise control over 
and drive all other elements of the ACRS. Its other primary function is 
to provide all resources, both hardware and software, necessary to allow 
efficient software development. As noted earlier, the level of 
utilization of the computer complex In some facilities may be such as to 
allow the host computer to provide both simulation and software 
development capability on a time-shared, non-interfering basis. In 
others, the level of activity will preclude this type of operation and 
will require that a separate computer be dedicated to the software 
development function. 

In either case, the computer designated for software development use must 
provide certain basic capability insofar as its software operating system 
is concerned. As a minimum, it should include the following features: 

a) A disc-based, hierarchical file system which provides adequate 
protection and privacy of individual files. 

b) Ability to perform time-shared interactive and batch processing. 

c) Capability to support multiple interactive terminals. 

d) Availability of compilers for various HOLs. 

e) Availability of an assembler for the host and peripheral computers. 

f) Sophisticated text editing and word processing capability for use in 
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creating, documenting and maintaining configuration control of the 
simulation software packges. 

g) A structure which allows additional routines to be added easily when 
required to facilitate software development activities. 

4. 4. 2. 9 Software System Design Tasks 

The following tasks must be accomplished in order to design the ACRS 
software system: 

a) Establish design requirements for the total ACRS software system, 
including both the operational simulation software and the software 
development system. 

b) Identify the aircraft type (or types), systems and external effects to 
be simulated and determine the optimum iteration rate for each. 

c) Identify the software packages required to allow research and 
maintenance personnel to control operation of the ACRS. 

d) Perform a top-down structured design of the total software system, 
identifying all required modules and specifying their interface 
characteristics. Include all interfaces with purchased software packages 
such as the visual system software. 

e) Specify the distribution of the software modules among the host and 
peripheral computers. 
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f) Select the HOL to be used. 

g) Design, code and checkout the required software modules. 

h) Integrate the individual modules into an overall ACRS software 
system. 

i) Provide documentation to the level required to maintain configuration 
control of the software system. 

4.4.3 I/O SYSTEM 

The I/O system provides the interface between the simulation software 
contained within the host and peripheral computers and the hardware 
components associated with the simulator cockpit. As such, it is a major 
factor in determining the overall operational capabilities of the 
simulation facility. Selection of the appropriate I/O system 
architecture is thus one of the more critical design considerations 
involved in configuring the ACRS. Once the basic architecture has been 
specified, a secondary consideration is the question of whether it is 
more cost effective to purchase an off-the-shelf system or to configure 
one from available components. 

4.4.3. 1 System Architecture 

The two competing I/O system architectures applicable to real-time flight 
simulation can be characterized by the terms centralized I/O versus 
distributed I/O. A centralized architecture involves direct control of 
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the I/O system by software contained within the host computer. This 
concept is illustrated in simple block diagram form in Figure 4-10. The 
contrasting distributed I/O architecture is illustrated in Figure 4-11. 
In this case, overall control still resides within the host computer 
software, but the individual I/O operations are accomplished under the 
direct control of a number of peripheral computers (microcomputers) 
located throughout the ACRS. Software is included within the peripheral 
computer to: 

a) Control the individual I/O components. 

b) Provide any data formatting and conversion required. 

c) Communicate with the host computer for transfer of I/O parameters when 
necessary . 

Of the two architectures, the distributed approach offers significant 
advantages, several of which are enumerated below: 

a) The host computer is relieved of the software burden of directly 
controlling the I/O operations and formatting the variables. 

b) The I/O system is composed of a number of powerful modules employing a 
common design. As such, it is inherently expandable simply by the 
addition of standardized modules to satisfy changing simulation 
requirements. 
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FIGURE 4-10 . CENTRALIZED I/O ARCHITECTURE 




I/O SYSTEM MODULE 



FIGURE 4-11 . DISTRIBUTED I/O ARCHITECTURE 
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c) The ease with which the system can be expanded implies a high degree 
of flexibility. The availability of standardized modules make it 
possible to easily reconfigure the ACRS by adding, deleting or relocating 
the modules within the simulation facility as required. 

d) Each of the distributed modules is a very powerful element by virtue 
of the intelligence provided by its controlling microcompter. 

e) The I/O process can be placed where needed — near the source or 
destination of the signals as appropriate. 

f) Packaging of I/O capability within compact modules offers the 
potential for significantly reducing the initial cost of fabricating the 
ACRS. For example, complex flight station panels, complete with I/O, can 
be fabricated separately, and simply plugged into the cockpit rather than 
having to wire the panels to the I/O system after installation (a much 
more difficult, time consuming and costly procedure). Further, the 
availability of complex panels, complete with I/O, in simple plug-in form 
implies that the cockpit can be easily reconfigured to satisfy changing 
research requirements. 

g) While designed primarily to control the I/O operations, the 
microcomputers included within the various modules possess the potential 
to perform additional computational tasks. As such, they can be 
programmed to perform a variety of tasks designed either to further 
relieve the host computer of some of its computational burden or to 
provide additional features not previously available within the 
simulation facility. 
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As a result of its inherent power and flexibility, the distributed I/O 
architecture should be implemented within a modern flight simulation 
facility such as the ACRS. 

The distributed I/O architecture may be implemented in a number of ways 
using a variety of components and techniques. As noted earlier, an I/O 
system may either be purchased as a complete operational package or 
configured from available components. The primary design concern is 

achievement of the full flexibility offered by the distributed approach, 
not necessarily the details of the system used to accomplish it. 

As an example of the type of flexible I/O system which can be easily 
configured from available components, consider a system composed of 
individual I/O modules built around the TM990/101 microcomputer. In 
addition to being a powerful microcomputer fully supported by a variety 
of development hardware and software, the TM990/101 offers a number of 
further advantages in the variety of chassis configurations, power 
supplies and general purpose interface cards available. The available 
interface cards include analog converter cards, a discrete interface card 
providing 64 inputs, 64 outputs or a combination of the two and a 
4-channel digital/synchro converter card. Figure 4-12 illustrates the 
way in which this type of standard I/O module can be employed to greatly 
simplify the interface with a conventional flight engineer's panel. 
Again, this example is included merely to illustrate the concept. 
Similar nodules can be structured around other available microcomputers 
and converter components. 
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FLIGHT ENGINEER'S PANEL 




FUEL MANAGEMENT 

ENVIRONMENTAL CONTROL 

ELECTRICAL CONTROL 

ENGINE INSTRUMENTS 

13 INSTRUMENTS 

9 INSTRUMENTS 

14 INSTRUMENTS 

17 INSTRUMENTS 

41 DISCRETE IN 

12 DISCRETE IN 

26 DISCRETE IN 

8 DISCRETE IN 

64 DISCRETE OUT 

32 DISCRETE OUT 

42 DISCRETE OUT 

6 DISCRETE OUT 

13 ANALOG IN 

10 ANALOG IN 

14 ANALOG IN 

32 ANALOG IN 


5 ANALOG OUT 




I/O SYSTEM MODULE 



TO 

HOST 

COMPUTER 


J 


FIGURE 
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APPLICATION OF STANDARD I/O SYSTEM MODULES 






4. 4. 3. 2 System Implementation 


Current technology aircraft will in the near term continue to use a large 
number of individual electromechanical instruments, discrete controls and 
switches within the cockpit. The trend of future aircraft designs, 
however, is obviously oriented toward use of a smaller number of 
integrated electronic displays and multifunction keyboards to provide the 
necessary interface with the crew. As a result, flight simulation 
facilities oriented toward the two generations of designs present 
somewhat different I/O requirements. The existence of these differences 
further highlights the advantages of the distributed I/O architecture. A 
general-purpose facility such as the ACRS will, during its lifetime, be 
configured to simulate a variety of types of aircraft employing the 
entire spectrum of available technology, flexibility of the distributed 
I/O system will be a vital factor in determining the ease with which the 
ACRS can be reconfigured to satisfy the multitude of research 
requirements which will be imposed upon it. 

The basic differences in the two approaches to cockpit design must be 
recognized along with the fact that the interim period will certainly see 
a mix of the two types of technology within the cockpit. Design of the 
I/O system for the ACRS must, therefore, provide for interfacing both 
conventional analog and advanced data bus-compatible equipment. For 
conventional analog-type interfaces, the basic design decisions involve 
specification of the types of signals to be handled (and thus the types 
of converters required) as well as the number of channels of each which 
must be provided. In general, the I/O system must provide 
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analog/digital, digital/analog, synchro/digital, digital/synchro, 
discrete input and discrete output capability. The number of channels 
required is obviously a function of the specific cockpit configuration of 
the type (or types) of aircraft to be simulated. Due consideration must 
be given, especially in the case of a research simulator, to provisions 
for expansion of the number of channels to satisfy future needs. 

Design of the necessary data bus-compatible I/O capabiity involves three 
considerations : 

a) The basic philosophy as to the way in which data buses are to be 
employed in the overall simulation facility. 

b) The types of bus structures to be accommodated. 

c) The number of each type of bus to be provided. 

Concerning philosophy of use, the basic data bus concept offers a number 
of advantages in the implementation of airborne systems — improved 
integration and control of the various systems, simplified interfaces and 
reduced wiring complexity to name a few. These same advantages apply 
equally well to the implementation of a general-purpose flight simulation 
facility and should be fully exploited in the design and construction of 
the ACRS. 

Two distinct possibilities exist for the effective use of data bus 
techniques within the ACRS. The first of these is the more obvious one 
in which the availability of the appropriate data bus will allow actual 



AVE hardware to be easily included as part of the overall simulation. 
This concept was illustrated earlier in Figure 4-2 which includes 
provisions for the optional installation of bus-compatible AVE components 
within the ACRS. This is an extremely powerful feature which, when 
coupled with a modularized software architecture, will provide a high 
degree of simulation flexibility. Simulation of a given system can be 
accomplished either by a software model or by the actual hardware as 
appropriate to the research task. If desired, competing hardware designs 
can be easily installed and compared, with the bus-compatibility feature 
eliminating many potential interface difficulties. 

The second possibility for application of data buses within the ACRS 
involves their use in providing interfaces among the host computer, the 
peripheral computers, the simulator cockpit and the various consoles. 
This approach can offer significant savings in the construction, 
operation and maintenance of a flight simulation facility by greatly 
reducing its wiring complexity. For example, the distributed I/O concept 
is totally compatible with the use of data buses to interconnect the host 
computer with the various I/O modules. This is, in fact, a very simple 
way in which the necessary electrical interfaces can be accomplished. 

The application of data buses within the ACRS is somewhat unique in that 
it provides several significant advantages while imposing no offsetting 
disadvantages. Basically, the availability of appropriate data buses in 
conjunction with the necessary analog-type I/O signals ensures that the 
facility will possess the necessary flexibility to accommodate changing 
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flight simulation requirements, many of which cannot be predicted at this 
time. 

The specific type (or types) of data buses to be implemented must be 
addressed on a simulator-to-simulator basis, taking into account the 
potential uses for which each facility is designed. A facility dedicated 
to investigation of commercial operations will certainly include the 
ARINC 429 data bus while one oriented toward military aircraft will 
include at least the MIL-STD-1553 data bus. In actual practice, each 
simulator may well include both types since in the near term AVE systems 
which can be effectively utilized within the various facilities may be 
designed to be compatible with either ARINC 429 or MIL-STD-1553, but not 
both. In any event, an initial decision to install one type of data bus 
within a given simulator will not preclude installation of the other type 
at some later date if the need arises. 

In addition to the buses mentioned above, the EIA RS-232C bus will be 
used extensively within the ACRS, primarily to provide communication 
between the computers and various peripheral devices such as CRT 
terminals. The IEEE 488 data bus may be applicable in certain instances, 
particularly in interfacing various portions of the data acquisition and 
recording system with remaining elements of the ACRS. In addition, the 
IEEE 488 standard includes features which can be employed to easily 
implement intercomputer data links. 

Once it is decided which buses are applicable to a given simulator, the 
question as to the number of each type to be installed must be 
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addressed. Again, this is a function of the overall design criteria of 
the facility itself. 

In summary, effective utilization of data bus techniques depends somewhat 
upon the specific uses envisioned for each ACRS. Generally, however, 
availability of data buses appropriate to the facility's intended use 
will greatly enhance its overall flexibiity as well as its potential for 
expansion. 

4.4. 3. 3 I/O System Design Tasks 

The following tasks must be accomplished in order to design the I/O 
system: 

a) Establish overall design requirements for the I/O system. 

b) Design the I/O system architecture. 

c) Identify the types of conversion necessary and the the number of 
channels required within the ACRS. 

d) Identify specific data buses to be used within the ACRS and provide 
for their installation and implementation. 

e) Generate the documentation required to establish configuration control 
of the I/O system and to facilitate its maintenance. 
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4. 5 SIMULATION ENVIRONMENTAL SYSTEMS REQUIREMENTS 


The simulation environmental systems as described in this section create 
the environment in which the flight station is immersed. The systems 
that are discussed in this section are the visual, motion and aural 
systems. 

4.5.1 VISUAL SYSTEM 

The most important element of the ARCS, external to the aircraft 
simulation itself, is the visual scene presentation. There are several 
reasons for this. The development of new operational techniques in the 
terminal area demands a very realistic visual presentation for valid 
evaluation. Ground operation in a full mission simulation, particularly 
high speed turn off, is a very important element in decreasing aircraft 
spacing and must not be adversly affected by an inadequate visual 
presentation. Extensive control of light levels, fog and ha 2 e, ceiling, 
and RVR are required for terminal area investigations. The most 
important phase of the scene generation is the terminal area 
presentation. A multiple airport complex capability is necessary to 
evaluate procedures and performance under different conditions. Terrain 
scene generation during the enroute phase, although highly desirable, is 
less important since it can be masked by enroute weather. 

The functional requirements for a visual system to provide these 
capabilities are presented in the following sections. 
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4.5. 1.1 General Requirements 


The heavy emphasis on the visual requirement dictates the highest degree 
of realism practically possible. Color scenes are required to give the 
crew approximately the same capability to discriminate features as they 
would have in the real world situation. 

Flexibility of scenes, particularly different airports, will be required 
for the full mission scenario. This capability is most cost effectively 
achieved with computer generated scene systems. The requirements that 
will increase the cost of a computer generated scene system are daylight, 
and high degree of realism. Overall this type of scene generation 
remains the most cost effective, with the ratio continuing to improve. 

The system selected for an ACRS should have full day/night capability and 
variable dawn/twilight lighting levels with additional horizon intensity 
adjustment. 

4.5. 1.2 Field-of-View 

The extensive use of this type of facility for research of circling or 
curved approaches places the most stringent requirements on the overall 
display system f ield-of-view. In a facility for developing aerial 
refueling techniques, stringent requirements also exist. The 
f ield-of-view does not completely describe the need during cross cockpit 
viewing requirements. Window display units tend to break up as a scene 
traverses from one window to the next. The ideal solution is to project 
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a continuous scene around the flight station, eliminating the break up 
and giving a viewing volume that is adequate for cross cockpit viewing. 

Based on these assumptions, the f ield-of-view requirements for the flight 
station are: 

180 Degrees Horizontal 
45 Degrees Vertical (Minimum) 

55 Degrees Vertical (For aerial refueling) 


4-5. 1.3 Terrain Features and Airfield Marking 

All prominent features in the terminal area such as passenger terminals, 
hangers, roads, towers, etc., and nearby towns or housing areas must be a 
part of the visual scene. In addition, all runway features such as 
lighting, painted patterns, overrun areas and tire marks need to be 
modeled in detail. All of these features must be modeled in three 
dimensions with the proper perspective shading, color and occultation. 

4.5. 1.4 Weather 

The visual system must be capable of simulating a wide variety of weather 
conditions. Visibility must be selectively restricted due to both cloud 
or overcast conditions and fog or haze. The overcast height should be 
adjustable from zero to 40,000 feet, and cloud tops should be adjustable 
from 20,000 to 40,000 feet. Visibility through haze or fog must be 
controllable from zero to 5 miles, and runway visibility range must be 
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independently adjustable down to zero. Scud cloud conditions with fade 
in and out at random intervals should also be simulated. 


4.5. 1.5 Traffic 

The emphasis on experiments in the terminal area, and with decreased 
traffic intervals means that much of the simulation will take place in 
the proximity of other aircraft. This traffic must be visible to the 
simulator crew during VMC conditions. The visual system must have the 
capability of presenting a minimum of two aircraft targets under computer 
control to provide the required traffic. 

4.5. 1.6 Visual System Control Requirements 

All features of the visual system should be controlled from a remote 
panel that can be installed on the test conductor's panel. The intensity 
of the approach, strobe, VASI, and runway lights should be individually 
controllable, and should have individual on/off capability. The horizon 
intensity and runway surface brightness must be controllable. All 
intensity controls should have 5 levels of brightness with equal 
increments. 

4.5.2 MOTION SYSTEM 

Although the trend in recent years has been to use full 6 DOF motion 
system for transport category aircraft, questions concerning their 
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contribution to the simulation, versus the relatively high cost have 
arisen. The general feeling among those submitting their facility 

requirements and discussing planned research indicates that a motion 
system was a low priority item. The only concern mentioned was the loss 
of realism during ground operation, specifically, push back, brake 
release and vibration during taxi. These "motion" cues could be 
accomplished with far less than a 6 or even a 3 DOF system. 

The other area requiring a trade-off decision concerns the use of a 180 
degree wrap-a-round projection system for the visual display. If this 
type of display is used it would be very difficult to operate with a 
motion system. 

4.5.3 AURAL SYSTEM 

The sound system for the simulation must provide the aural cues that are 
heard by the crew member, and are probably used in the performance of his 
duties. These sounds must be automatic and function as a result of the 
state of the simulator. They must vary in tone and intensity and be 
induced into the flight station to simulate their representive location. 

Some representive sounds that should be simulated are: 

Ground Operation 

Power Carts 

Engine Start, Idle, Reverse 
Taxi and Runway Noise 
Flight Station Equipment & Cooling 
Air Conditioning 
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Flight 


Engines 

Strut Extension (if audible) 

Aerodynamic Noise 
Gear & Flap Retraction 
Spoiler & Flap Buffet 
Gear & Flap Extension 
Touchdown Impact 

Abnormal 

Stall Buffeting 
Compressor Stall 

This is a partial list but may include some items that do not apply to 
the simulated aircraft. 

4.6 TEST CONDUCTOR CONSOLE 

The Test Conductor Console should include CRT displays and multifunction 
keys in an uncluttered, yet complete control panel for all simulation 
functions normally performed by the test conductor. The CRT displays can 
be monochromatic or multi-color and can have calligraphic capability. 
The use of keys adjacent to the CRT allows maximum flexibility rather 
than having a fixed number of dedicated keys. Each key can be used for a 
function designated on the CRT for each different display or page .called 
up on the CRT. A certain number of the keys would be dedicated for 
special purpose functions such as page forward or reverse or for specific 
topic areas such as malfunctions or approach parameters. 

Other types of keyboard systems can be used where the keys have multiple 
legends built in, and display only the legend appropriate to the current 
function of the key. This does have some limitations in terms of number 
of legends per key; however, displaying the function on the CRT as part 
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of the display eliminates this difficulty and gives maximum flexibility. 
The test conductor can perform pre-flight, inflight or post-flight 
functions. For example, test scenarios would be programmed pre-flight, 
monitoring and fault insertion during inflight, and data analysis and 
replay at post-flight phases. 

The test conductor console should include: 

a) Communications (Flight Station, ATC Console, and Computer Complex) 

1) Frequency Readout for all communications/ 

Navigation Equipment 

2) Indicators - Position of transmitter 
selector and systems being monitored 

3) Indicators - Position transmitting 

b) Test Control Panel 

1) Test start/stop/reset 

2) Freezing of specific or all parameters 

3) Repositioning of aircraft 

4) Time scale changes 

5) Replay of certain time frame 

6) Emergency shutdown of any or all systems 

c) Visual System Controls Panel 

d) Flight Station Video Panel 
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1) Monitors 

2) Camera zoom and pan controls 

e) Flight Station Display Repeaters 

1) Monitors 

2) Select controls for specific display units. 

f) Scenario Control Panel 

1) Initialization parameters 

o Specific mission or scenario profiles 
with all communication, navigation, and 
environmental factors preplanned. 

o Setup of all weather radar functions 
such as weather type and location. 

2) Inflight conditions 

o Malfunctions and emergency conditions - 
initiation of subtle catastrophic 
malfunctions. 

o Time changes - expansion or contraction 
of specific flight segments. 

o Observation of track plots, approach graphs 
or other selected real time parameters. 
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o System status and flight situation including 
systems activated, parameter monitoring, 
and event, sequencing information, comm/nav 
time system status, any flight instrument, 
engine performance instrument or caution 
and warning status. 

3) Post flight analysis 

o Playback of any portion or all of flight 
exercise to allow post-flight debriefing 
and analysis. 

The usual location for the test conductor console is in the simulator 
cab, allowing the test conductor complete control and monitoring 
capability over the entire simulation. It may be desirable, however, for 
the test conductor station to be located outside the confines of the cab 
itself. Should this be the case, additional information from the cab 
could be obtained through the use of multiple TV video cameras situated 
in appropriate locations in the cab. 

In some cases, it may be desirable to have two test conductor consoles, 
one in the cab and the other located remotely outside the cab. All 
functions provided by the console can be permitted to operate in a 
parallel manner such that the computer complex could accept inputs from 
either console separately but would have to make a software judgement 
concerning simultaneously inserted or conflicting inputs. 
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4.7 COMPUTER CONTROL CONSOLE 


The variety of computers necessary to efficiently accomplish all 
computational tasks requires an integrated control station to allow 
facility personnel to exercise control over and monitor the performance 
of all aspects of simulator operation. Specific functions provided by 
the computer control console include: 

a) Unified control of the computer complex including all computers, their 
peripherals and the I/O system. 

b) Initiation of automatic sequencing of ACRS components. 

c) Control of manual activation of system elements. 

d) Display of the operational status of the computers, peripherals, 
sensors and other components of the ACRS. 

e) Interactive communication with the Test Conductor and Air Traffic 
Control consoles to provide the coordination required during research 
activities. 

f) Real-time interrogation of the various computers to allow their memory 
contents to be examined and/or modified as required to facilitate either 
simulator operation or software development activities. 

To ensure both utility and flexibility, the computer control console 
should be built around one or more CRT display/multifunction keyboard 
elements. The number of such elements required should be a function of 
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the specific conf iguation implemented, and the overall research goals of 
the facility. Discrete controls and displays must be integrated into the 
console when appropriate for a given function. In certain simulators, 
the console should be directly interfaced with the host computer which 
will contain the software necessary . to implement the desired 
control/display functions. In others, the console should contain its own 
computer which would be interfaced with the host. In either case, the 
interface of the computer control console with the other functional 
elements of the ACRS would be accomplished indirectly through the host 
computer. 

Use of CRT displays and multifunction keyboards to provide the desired 
interactive control capability ensures that the initial computer control 
console design will be sufficiently flexible to expand with the ACRS to 
accommodate changing research requirements and tasks. Generally, the 
need for new control/display functions requires only that the existing 
software be modified to incorporate the new features. Modular design of 
both the hardware and software elements will allow the console to be 
easily modified in response to either a minor simulator reconfiguration 
or a major simulator expansion. 

4.8 DATA ACQUISITION AND RECORDING 

The ACRS will be used for a wide variety of research and development 
activities related to the operation, performance and impleraentaton of 
advanced aircraft-related systems, concepts and techniques. As such, it 
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must include the hardware components and software packages that are 
required to acquire, record, and analyze data generated during the 
various test sequences. Specific functions involved in this aspect of 
simulator operation include: 

a) Ability to interactively specify the data parameters pertinent to a 
given research task. 

b) Acquisition and formatting of the selected parameters. 

c) Display of selected parameters in real-time or recording of them as 
appropriate. 

d) Reduction of recorded data to aid in post-test analysis and 
evaluation. 

In general, the ACRS must be capable of generating data in digital, 
analog, audio and video form. The data acquisition and recording system 
must therefore be capable of accommodating any of these formats. While 
the specific data acquisition and recording requirements would vary with 
the type of facility developed, each should include the following types 
of equipment: 

a) Audio recorders with playback capabiity 

b) Video recorders with playback capabiity 

c) X-Y plotters 


d) Strip chart recorders 



e) Magnetic tape recorders 


f) CRT terminals with hardcopy capabiity. 

The data system must interface with all functional elements of the ACRS 
to acquire the necessary parameters. Use of data bus techniques to 

implement the simulation facility as discussed earlier will make it 

easier to gain access to the required data. The IEEE 488 data bus would 

be particularly appropriate here, as a wide variety of instrumentation 
components are available today with IEEE 488-compatible interfaces. 

An interesting potential use of the data acquisition and recording 

capabilities of the ACRS is the accurate recreation of previous events. 
If the system is properly designed, the role of the data acquisition and 
recording system can be reversed to allow recorded information, in a 
variety of forms, to serve as the input stimuli to the simulator. In 
this mode, the simulator would respond with a very high degree of 
fidelity and repeatibility to the recorded data so as to create, within 
the carefully controlled and instrumented simulator environment, 
sequences of events which may have occurred previously. 

Several interesting applications of this replay capability can be 
postulated. They include: 

a) The ability to repeat with a high degree of accuracy specific test 
sequences, eliminating variables due to the human test subjects. Replay 
of these sequences can be used either to demonstrate the results or to 
allow detailed analysis and evaluation. In some cases, the research task 
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nay be aided by the ability to replay the test in "slow notion" while 
retaining accurate synchronization of all effects. 

b) The ability to transfer experimental results from one facility to 
another for use in a variety of research studies. 

c) Recreation of conditions encountered during actual flight. This 
feature could be used either to evaluate flight test results or to 
investigate incidents which occurred during flight. 

d) Replay of flight sequences for crew training purposes. 
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5.0 CONCLUSIONS AND RECOMMENDATIONS 


5.1 COMMONALITY OF RESEARCH NEEDS 

During the investigation of research needs with various industry, NASA 
and Air Force organizations, it became apparent that there is some degree 
of overlap in planned areas of research. This is vividly evident in 
Figure 3-1, shown previously. The division of research into broad areas 
in this figure does not present the entire picture, however, because 
although more than one organization is planning research in a given area, 
the specific goals and ultimate application of that research may differ 
considerably. 

It would be a misnomer to call this a duplication of effort. The 
specific goals range from the development of concepts and procedures to 
the development and testing of hardware. Some of the research areas, 
such as development of the aircraft interface with the 1990' s ATC 
environment will have significant long term impact on both the aviation 
industry and related industries. These areas should be investigated from 
every practical angle to assure that decisions are based on a total data 
base that includes operationally sound techniques and criteria that have 
been subjected to extensive study and investigation. 

As a part of the study documented by this report, methods of exploiting 
the similarity in facility requirements were explored. The following 
sections describe specific areas in which this commonality of functional 


-114 - 




requirements could provide a far more effective program to resolve the 
issues confronting future development of the air traffic system. 

The survey of the research needs of the various organizations involved in 
advanced flight station studies did not indicate any major areas of 
omitted research. Continued coordination among the organizations is 
recommended to point out areas of additionally required research that 
might grow out of planned research or changes in the present constraints 
that have been assumed at this time. 

5.2 SPECIFIC RECOMMENDATIONS FOR EXPLOITING COMMONALITY 

One of the major benefits that can be realized from this task is the 
exploitation of areas of commonality in the development of the various 
research facilities being planned. These benefits can accrue in areas 
such as reduced total cost, faster facility development, and the 
capability to transfer experiments between facilities. 

During the coordination required to develop an understanding of research 
needs and requirements, almost without exception, intense interest was 
expressed in sharing in the common development of basic simulator 
requirements. 

Analysis of the individual facility developers' requirements, points to a 
number of specific tasks that should be implemented immediately for use 
by almost all agencies involved in this study. 
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5.2.1 FLIGHT STATION SHELL 


One of the requirements established for this study was to investigate use 
of the flight station shell recently developed by Boeing. Lockheed's 
investigation determined that use of this flight station shell and base 
is a feasible and cost effective approach that would enhance the 
commonality of facilities. 

5.2.2 COMPUTER COMPLEX 

An important purpose of this study has been the identification of common 
elements within the computer complexes. A corollary purpose has been the 
suggestion of ways in which this commonality can be exploited to 
eliminate duplication of development effort and thereby reduce the life 
cycle costs of each facility. Emphasis has thus been placed upon 
identification of ways to achieve the desired level of functional 
commonality, recognizing that the common design criteria can, in some 
cases, be satisfied by a variety of hardware system configurations. 

A network composed of a host and several peripheral computers is 
recommended for the ACRS. In addition to providing the real-time 
computational capability required, the network architecture would make it 
possible to achieve the desired level of flexibility and expandability 
within the simulation facility. Ideally, the computers utilized within 
the basic computer complex of each facility would be identical. The 
computer resources already in-place must be recognized, however, and this 
existing capability must be integrated into the framework of the common 
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computer complex. As a minimum, the basic computer complex can be 
utilized to provide the common simulation, control, and data gathering 
functions of the ACRS. 

Development of a common software system structure would provide a high 
level of functional commonality. Use of a common HOL to implement the 
majority of the software would drastically reduce the software system 
life cycle costs and would make possible the exchange of software 
packages among the various facilities. In addition, the inherent 
transportability of HOL software would simplify the integration of the 
basic ACRS computer network with existing computer facilities. 

Implementation of a modular I/O system would provide the interface 
flexibility required to allow the ACRS to be easily and quickly 
reconfigured in response to changing research requirements. Multiplex 
data bus techniques can be very effectively used to simplify the 
necessary interfaces among the various functional elements of the 
facility. 

5.2.3 DETAIL TASKS 

The following are those specific common tasks that should be implemented 
in beginning the design process. 

a) Design of the ACRS baseline flight station configuration, which 
includes detail design of all features required to facilitate 
reconfiguration of the flight station to satisfy changing research 
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requirements. It would involve design of consoles, panels, primary and 
secondary controllers, display device installation, etc. In addition, 
definition of all auxiliary items within the flight station such as 
cupholders, ashtrays and trim items would be included. 

b) Definition of the design details of all common elements such as 
cooling, lighting, communications facilities, intrafacility wiring, the 
electrical power system and all safety-related features and systems. 

c) Flight station integration by a single organization to assure 
interchangeability and utilize experience gained during first buildup. 

d) Design of the ATC and Test Conductor consoles and definition of their 
interfaces with other elements of the ACRS. 

e) Development of specific software system requirements and design of the 
overall software structure. 

f) Identification of the aircraft systems to be simulated and 
specification of the appropriate iteration rate and computer (host or 
peripheral) to be used to simulate each one. 

g) Definition of an advanced aerodynamics data base. 

h) Definition of advanced aircraft systems such as primary/ secondary 
flight controls, both manual and automatic, including active control 
systems . 
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i) Development of a simulation model to implement the advanced 
aerodynamics data base and aircraft systems. 

j) Identification of potential malfunctions and their consequences. 

k) Selection of specific malfunctions and their implementation for 
effective use within the ACRS to facilitate research, development and 
training activities. 

l) Definition of the ways in which data bus techniques can be used within 
the ACRS to facilitate operation and minimize life cycle costs. 

m) Identification of specific data buses to be used, and design of their 
implementation within the ACRS. 

n) Design of the computer complex configuration, including all interfaces 
among the host computer, peripheral computers and I/O system. 

o) Design of the hardware and software elements of the common I/O 
module. 

p) Definition of the data acquisition and recording requirements of the 
ACRS. Specification of the hardware and software modules to be used and 
their interfaces with other ACRS elements. 

q) Definition of the requirements for self testing of elements within the 
ACRS. 
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APPENDIX A 


SIMULATOR REQUIREMENTS AND GROUND RULES 

This appendix consists of a summary of the future research needs and 
requirements as submitted by both NASA-LaRC and NASA-ARC, and a 
compilation of typical research needs of industry. Inasmuch as 
implementation of the USAF TACS 2000 program is not nearly so near term, 
a definitive set of requirements and research needs does not exist at 
this time. 

LANGLEY RESEARCH CENTER 
ADVANCED MISSION SIMULATION 

Purpose of Facility: 

Develop efficient operating concepts, procedures and functional 
requirements for airborne avionic systems to operate effectively in a 
1990's airspace environment. 

a) Quantify benefits and sensitivites of advanced concepts, systems, and 
procedures. 

b) Establish flight management emphasis and functional criteria for 
design and operation of an advanced flight station and associated 
systems, procedure and information interfaces. 

c) Verify credibility and promote early acceptance of new technology Into 
the commercial fleet. 
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Research Time Frame: 


a) Support NASA/Industry research milestones for FY-82 through FY-88. 

b) Update facility in FY-84/85 to full-workload capability. 

Configuration Envelope: 

a) Cab geometry /dimensional configuration should consider the recent 
Boeing design. 

b) The flight station should be a basic two-man crew configuration 
capable of expanding to three-man configuration within limits of the TCV 
B-737 cabin envelope. 

c) The flight station should not be constrained by present and near-term 
limitations (e.g. panel depth, geometry, electronics packaging, etc.) 

Functional Envelope And Interfaces: 

a) Capability and workload envelope to realistically simulate all-mission 
gate-to-gate operations, including abnormal or failure intensive workload 
options (as a module for later incorporation). 

b) Redundancy should be provided only for operational expediency. 

c) Hardware should reflect FY 1981 state-of-the-art. 

d) Maximize use of CRTs and Dot-Matrix displays (LED, LCD, EL and/or 
Plasma) and multifunction key boards for: 
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-Primary Flight 
-Engine 

-Flight and System Management 
-Navigation/Communication and Advisory 
-Caution and Warning. 

e) Use fly-by-wire (electronic) digital control systems and electrical 
throttles. 

f) Programmable multi-function cockpit displays and interface 
reconf igurable without significant change to host computer. 

g) Interface and interact flexibly with cruise and terminal area traffic 
models and with simulated ATC controller stations. 

h) Enable expedient transfer of simulator developments (algorithms, 
software and flight procedures) to aircraft experimental systems for 
flight verification. 

i) Feature higher-order software language that is compatible with 
resident support software. 

j) Ensure computer configuration allows use of display and control 
software in either simulation or airplane. 

Functional Modularity: 

a) Possess high degree of modularity to enable maximum flexibility of 
systems. 
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b) Provide for alternative display methods and programmable display 
generators to reflect opportunities afforded by technology developments 
projected through 1981. 


- DISPLAYS AND CONTROLS 
CRT vs Flat Panel Option 

CRT Shadow-Mask vs Color (CRT's & Dot-Matrix) 
Single (large) vs Multiple (small) Displays 
Writing Speed, Brightness, Contrast Ratio, etc. 
Ambient Lighting in Cockpits 


- PROGRAMMABLE DISPLAY GENERATOR 
Electrical Inputs and Outputs 
Stroke, Raster and/or Hybrid 
Symbology, Formats, Line Resolution, 
Color Capabiity, etc. 

Interface with Host Computers 


- PRIMARY FLIGHT CONTROLLERS 
Center Stick 
Side Arm Controller 
Brolly Handles 
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Sensors, Data Processing, and Test Operations: 
a) Provide 

- Oculometer for each crew station 

- Data bus capability and flexibility for 
reseach modularity and data extraction 

- Experimenter station for time/cost/ 
manpower-effective operations 

- Real-time quick-look data review capability 

- Integrated workload measurement battery 
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AMES RESEARCH CENTER 
MAN-VEHICLE SYSTEMS RESEARCH FACILITY 
RESEARCH SUPPORT REQUIREMENTS 


I. General 

In general, it is not intended that the Advaned Technology Cockpit be 
used for exploratory research. Ames has a complement of part task 
simulators and basic laboratory apparatus that can be used for basic or 
exploratory research in aeronautical human factors. Rather the cab will 
the used, as will be the remainder of the Man-Vehicle Systems Research 
Facility, for those studies that require either high operational and 
systems fidelity with part of full crews or full mission operation with 
full c9ews. Both requirements imply that the cockpit be as much like a 
real aircraft as is practicable and that most if not all of the major 
flight and aircraft systems function in a realistic manner. 

In addition to this fundamental requirement, it is further required that 
performance of the part or full crew be measured in as broad a sense as 
possible. Categories of measurement shall include: 

1. Measures of system performance - rms flight path errors, control 
movements, airspeed, sink rate, power settings, etc. 

2. Measures of crew communication and coordination - video and 
audio recordings of crew interactions, observer ratings of crew 
activities and performance, and recordings of air/ground communication 
and information transfer. 
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3 


Analog measures of crew state and crew performance 


physiological measures such as heart rate, peripheral cardiovascular 
condition, breathing rate, eye point-of-regard, voice. 

4. Discrete measures of crew state and performance - reaction time, 
time estimate, crew rating and categorization, discrete decisions, 
performance on side tasks, crew-machine interactions. 

Other general guidelines for performance measurement shall include: 
minimum intrusion onto normal crew activities, flexible specification and 
storage of specific performance measures for a given experiment, 
efficient data base management, on-line and off-line data display, common 
time/event synchronization of separate performance measurement 
"channels." 


II. Specific Research Areas Supported 

1 . Human Error and Aviation Safety 

Specific research areas will arise from analyses of the existing 
Aviation Safety Reporting System data bases. Possible experimental 
scenarios include the study of crew behavior as a function of specific 
accident scenarios or classes of accidents involving 
communication/ information problems between air and ground personnel. 
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Performance measures would likely include cockpit observer analyses of 
crew performance, analog recordings of voice communications, and state 
information for all involved aircraft. 

2. Automation 

A major question is the degree to which automation of the cockpit is 
helpful/desirable from the perspective of crew behavior, workload, and 
performance. Two major issues are apparent at this stage: 

a. Skill Erosion - to what extent does/will dependence on 
automated equipment in the cockpit for functions currently manually 
performed result in the erosion of specific flying skills and how may 
deficits, if any, best be ameliorated. 

b. Failure Detection - what information logic/performance is 
optimal so that automated system failures may be detected and diagnosed 
with minimum latency and maximum effectiveness. 

Specific performance measures would likely include subsets of system 
performance (control errors, etc.) as well as measures of reaction time 
to specific system failures and discrete crew responses to equipment 
failures and malfunctions. Direct observation of crew performance may 
also be used. 
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3. Crew Information Requirements 


The major questions here revolve about the issues of the relative 
degree of responsibility between air crews and ground based control, be 
it automated or human. A related issue concerns the display requirements 
which derive from the various responsibility distribution scenarios. 

System performance measures here may necessarily involve more complex 
system considerations since more elements of the overall aviation system 
may be involved in any specific experimental scenario. For example, for 
the terminal area case in which multiple aircraft (piloted or "pseudo 
piloted") occupy a given volume of airspace, complete aircraft state data 
should be recorded at periodic intervals throughout a given simulation. 

Crew performance measures may also vary widely as a function of the the 
specific experimental design. Eye-point-of-regard, reaction time to 
system anomalies, blunders, and visual representation of traffic threats 
would likely be used, as would perhaps observer ratings of crew 
performance and interaction. Crew workload measures of physiological, 
voice, side task performance, etc., might also be used here. 

4. Human Factors of Advanced Crew Stations 

Specific research issues here center around the introduction of 
advanced systems into current technology flight decks and the design and 
crew utilization of advanced flight decks. 
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Since, to a great extent, crew workload and safety considerations will 
probably influence the evolution in the design of the use of systems like 
head up displays, advanced head down displays, caution and warning 
systems, speech input and output units, programmable display units, and 
multifunction displays and controls. Measures of workload, crew problem 
solving, and decision making will index performance in this category of 
study. For specific aspects of display work, eye point-of-regard 
measures may also be used. 

For CAWS work, measures of crew response to caution and warning signals 
will be emphasized. For this work it will be necessary to selectively 
fail simulated aircraft subsystems so that aircraft performance and state 
is consistent with the caution and warning "messages". It must be 
possible, in addition, to adequately monitor the coordination and 
management of the flight crew. For this, an on-board observer will be 
used. This individual should have available an automated and 
non-obtrusive means for systematically recording crew behavior. 

In general, studies in this category will place the greatest demands on 
the configuration flexibility of the simulator cockpits, including both 
the location of display and control subsystems as well as the location 
and number of crew members. 
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5. Air Crew Behavior 


Under the category of aircrew behavior will be included studies and 
training, workload and performance measurement, decision making, fatigue 
and crew complement. Taken as a whole, research studies in this category 
may involve the widest range of performance measures including those in 
all four of the categories listed in Part I above. 
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NASA-AMES RESEARCH CENTER 
MAN-VEHICLE SYSTEMS RESEARCH FACILITY 
PERFORMANCE CRITERIA AND DEVELOPMENT GROUNDRULES 


(1) Two cabs capable of full mission simulations: filing of flight 
plans, taxi, takeoff, climb, cruise, approach, landing and final 
roll-out ; 

(2) Independent or simultaneous operation of both cabs in the same 
airspace; 

(3) Full three. person crews, both simulator cabs, reconfigurable to 
two person crew, cab base and shell to be modified (stretched) version of 
the Ames "Interchangeable Cab"; 

(4) Functional representation of terminal area, tower and center air 
traffic control, current configuration; 

(5) Three (minimum) pseudopilot stations, each capable of simulated 
operation of six independent aircraft; 

(6) Current technology simulator cab to be equipped as a facsimile 
of a current commercial transport aircraft with all flight displays, 
controls and other major aircraft systems operable and functioning for 
three crew members; 

(7) Advanced technology cab to be equipped with computer generated 
display systems for flexible presentation of all primary flight and 
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aircraft systems data to three flight crew members; displays to be 
reconf igurable relative to location, information content and symbology; 

(8) Flexible and realistic intercommunication system to provide 
communication links between air and ground crews and between air crews, 
including provision of background communication, and to provide 
communication between the experimental flight and ground crews and 
simulation operators and experimenters; 

(9) Computer generated visual scene display generator, capable of 
storing and displaying (in real time) a data base consisting of at 
minimum, two terminal areas and visual conditions. Capabilities to 
include simulation of night, dusk, and limited day conditions and 
conditions of reduced visibility and ceiling; 2 channel scene to be 
switchable between simulator cabs; 

(10) Each cab to be equipped with a two window visual display 
system, one window each for pilot and first officer. Each display window 
to provide a 45 degree x 35 degree field of view (minimum) and a virtual 
image at optical infinity; 

(11) Visual scene generator to be capable of representing other 
visual traffic, during all three modes of operation. It shall be 
possible to control the the trajectory of this traffic either under 
program control or under experimenter control from either experimenter's 
console; 


-133 - 



(12) Each simulator cockpit to be equipped with a cabin sound 
generation system capable of creating a realistic cockpit interior noise 
environment. The sounds shall include those of each turbofan engine, 
including jet and turbomachinery noise during each phase of operation 
including startup, and of air conditioning noise, landing actuator gear, 
auxiliary power unit and other hydraulic system noise, and of runway 
rumble noise. Engine noise shall vary, in a realistic manner, as a 
function of engine RPM and thrust level, at minimum; 

(13) It shall be possible for the experimenter to introduce failures 
of the major aircraft systems independently in each of the two simulator 
cabs. Specific mode and timing of the failures shall be at the 
discretion of the experimenter; 

(14) It shall be possible to digitally record all data descriptive 
of the simulated flight envelope and aircraft system function for an 
entire aircraft mission as well as selected subsets of crew behavioral 
data (e.g. pilot and first officer control movements, etc.) under control 
of the experimenter. Means shall also be provided to retrieve and 
display selected channels of data, either for previously stored data or 
in real time; 

. (15) A system shall be provided to simulate a wide variety of aural 
warning signals, in each of the simulator cabs, under control by the 
experimenter. Signal specification shall be flexible with provision for 
both speech and non-speech sounds. Signal presentation shall be made in 
a realistic manner in each of the simulator cabs; 
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(16) Electrical, mechanical and structural provision shall be made, 
during construction of the building housing the simulation equipment, for 
the eventual installation of a hydraulically actuated six-degree of 
freedom motion base. Sufficient interface capacity to drive the motion 
base shall also be provided. 

(17) A computer-controlled test system shall be provided to perform 
evaluations of status and operability for all major electronic systems in 
each of the simulator cabs, for the visual scene generation and display 
systems, for the simulation computers, and for the experimenters' and 
simulation control consoles, to maximize operational efficiency and 
realibility; 

(18) A digital simulation computer or computers shall be provided to 
solve equations of motion for each of the simulator cabs, to model 
avionics, computer-generated instrumentation, to implement data 
collection, perform input/output operations, control each of the facility 
subsystems such as noise and warning sound generators, etc. and that, in 
general, shall control an entire simulation. The same or a separate 
digital computer shall also be provided to perform area simulation for 
the Air Traffic Control function. A program development capability shall 
also be provided as shall a sufficient hardware and software 
communication network to tie together all computation system components; 

(19) System software shall be provided to support high level and 
assembly level language processing as well as program editing, debug, 
etc. A nominal set of program modules shall also be developed including 
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flexible aerodynamic models for each simulator cab as driver modules for 
each of the facility systems under control by the facility simulation 
computer(s) ; 

(20) Primary flight controls to be of an advanced type, e.g. side 
arm. Brolly handles, or center stick. 
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TYPICAL INDUSTRY RESEARCH REQUIREMENTS 


1) Evaluate different types of displays, display formats, 
arrangements, etc. 

2) Evaluate limits of automation that can be implemented and still 
maintain the pilot as an effective system manager. 

3) Perform workload and performance evaluation with various levels 
of integration. 

5) Demonstrate the effectiveness of a master caution or positive 
alert panel. 

6) Explore crew complement issues. 

7) Explore application of voice recognition and voice speak-back 
concepts. 

8) Investigate techniques for integrating new ATC systems into the 
cockpit. 

9) Determine feasibility of software controlled switches for data 
entry (touch sensitive panels and LCD displays, etc.). 

10) Explore new aircraft subsystem control and display techniques. 

11) Development of closed-loop flying qualities. 
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12) Investigation of innovative approaches to enhance pilot control 
of flight (side arm controllers, etc.) 

13) Define and develop systems for control of flight on advanced and 
derivative aircraft configurations. 

14) Determine flying qualities requirements on active controls. 

15) Assess control system criticality. 

16) Assess pilot performance and safety related parameters. 

17) Evaluate flight worthy hardware and software and conduct failure 
effect studies. 


-138 - 



1. Report No. 2. Government Accession No. 

NASA CR159331 

3. Recipient's Catalog No. 

4. Title and Subtitle 

Advanced Flight Deck/ Crew Station Simulator 
Functional Requirements 

5. Report Date 

December 1980 

6. Performing Organization Code 

7. Author(s) 

R. L. Wall, J. L. Tate, and M. J. Moss 

8. Performing Organization Report No. 

LG80ER0035 

10. Work Unit No. 

9. Performing Organization Name and Address 

Lockheed-Georgia Company 
86 South Cobh Drive 
Marietta, GA 30063 

11. Contract or Grant No. 

NAS1-15546 

13. Type of Report and Period Covered 
Final Report 

October 1979-February 1980 

12. Sponsoring Agency Name and Address 

National Aeronautics and Space Administration 
Washington, DC 20546 

14. Sponsoring Agency Code 


15. Supplementary Notes 


Langley Technical Monitor: Leonard V. Clark 


16. Abstract 


This report documents a study of flight deck/crew system research facility 
requirements for investigating issues involved with developing systems, and 
procedures for interfacing transport aircraft with air traffic control systems 
planned for 1985-2000. 

Crew system research needs of NASA, the U.S. Air Force, and industry were 
investigated and reported. A matrix of these is included, as are recommended 
functional requirements and design criteria for simulation facilities in 
which to conduct this research. Methods of exploiting the commonality and simi- 
larity in facilities are identified, and plans for exploiting this in order 
to reduce implementation costs and allow efficient transfer of experiments 
from one facility to another are presented. 


17. Key Words (Suggested by Author(s) ) 


1 18. Distribution Statement 


Research Simulator Facilities 
Advanced Flight Deck/ Crew Systems 
Simulator Computer Complex 

Unclassified - Unlimited 
Subject Category 05 

19. Security Oassif. (of this report! 

20. Security Classif. (of this page) 

21. No. of Pages 

22. Price* 

Unclassified 

Unclassified 

142 



For sale by the National Technical Information Service, Springfield. Virginia 22161 





















End of Document 



